Policies & Procedures

East Africa Public Health Laboratory
Network Project
1.
Information Communication
C
Technology
echnology
Standard Operating Guidelines and Procedures
Manual
Visit us on: http://eaphln-ecsahc.org/

ecsahc.org/
EAPHLN/ICT/02/01 - ICT Standard Operating Guidelines and Procedures Manual
Prepared by
If you have any questions about this document, please contact the following individual:
Name
Date
ICT TWG
20/12/2013
Revision history
This section identifies revisions to this document:
#
Name
Revision
Description
Date
1.0
ICT TWG
V001
20/12/2013
1.1
Contacts
For more information about this manual please contact
Name
Position
Email
John Baptist Mugisha
ICT TWG-Chair
jbaptist.mugisha@gmail.com
Please also visit our web portal for further information on http://eaphln-ecsahc.org/
2 | East Africa Public Health Laboratory Network Project
Table of Contents
1
ORGANISATION/ICT/02/01/02 - INTRODUCTION .................................................................................. 12
ORGANISATION/ICT/02/01/02 - ELIGIBILITY FOR ICT RESOURCES AND SERVICES .................................. 15
ORGANISATION/ICT/02/01/03 - ICT RESPONSIBLE USE ......................................................................... 17
ORGANISATION/ICT/02/01/04 - ICT STANDARDS .................................................................................. 18
ORGANISATION/ICT/02/01/05 - STAFF AWARENESS AND COMMITMENT ............................................ 20
ORGANISATION/ICT/02/01/06 - USER ACCOUNT MANAGEMENT ......................................................... 21
ORGANISATION/ICT/02/01/07 ICT ASSESSMENTS (ICT AUDITS AND INSPECTION .............................. 23
ORGANISATION/ICT/02/01/08 - NETWORK CONFIGURATION ............................................................... 28
ORGANISATION/ICT/02/01/09 - SUPPORT AND MAINTENANCE ........................................................... 30
10
ORGANISATION/ICT/02/01/10 - HARDWARE ........................................................................................ 35
11
ORGANISATION/ICT/02/01/11 - SERVICE LEVEL MANAGEMENT (PROCUREMENT) ............................... 40
12
ORGANISATION/ICT/02/01/12 - EMAIL ................................................................................................. 42
13
ORGANISATION/ICT/02/01/13 - INTERNET USAGE ................................................................................ 47
14
ORGANISATION/ICT/02/01/14 - ANTI-VIRUS ......................................................................................... 51
15
ORGANISATION/ICT/02/01/15 BACK- UP ........................................................................................... 54
16
ORGANISATION/ICT/02/01/16 - ICT SYSTEM ACCESS CONTROL ............................................................ 60
17
ORGANISATION/ICT/02/01/17 - REMOVABLE MEDIA............................................................................ 65
18
ORGANISATION/ICT/02/01/18 - NETWORK ACCESS .............................................................................. 67
19
ORGANISATION/ICT/02/01/19 - THIRD PARTY NETWORK ACCESS ........................................................ 74
20
ORGANISATION/ICT/02/01/20 - PASSWORD ......................................................................................... 80
21
ORGANISATION/ICT/02/01/21 - PHYSICAL SECURITY AND ENVIRONMENTAL CONTROLS ..................... 88
22
ORGANISATION/ICT/02/01/22 - CHANGE MANAGEMENT ................................................................... 101
23
ORGANISATION/ICT/02/01/23 - SECURITY MONITORING ................................................................... 110
24
ORGANISATION/ICT/02/01/24 - GENERAL SOFTWARE GUIDELINE ...................................................... 117
25
ORGANISATION/ICT/02/01/25 - ICT QUALITY MANAGEMENT............................................................. 124
26
ORGANISATION/ICT/02/01/26 - INCIDENT MANAGEMENT ................................................................. 129
27
ORGANISATION/ICT/02/01/27 - CONTINGENCY PLANNING ................................................................ 137
28
ORGANISATION/ICT/02/01/28 - IT GOVERNANCE ............................................................................... 141
29
ORGANISATION/ICT/02/01/29 - IT STEERING COMMITTEE.................................................................. 147
30
ORGANISATION/ICT/02/01/30 - ICT PROCEDURES MANAGEMENT ..................................................... 149
31
ORGANISATION/ICT/02/01/31 - ICT PROJECT MANAGEMENT ............................................................. 151
32
ORGANISATION/ICT/02/01/32 ICT PROJECT CONCEPTUALIZATION AND APPROVAL ........................ 155
33
ORGANISATION/ICT/02/01/33 ICT PROJECT PLANNING ................................................................... 157
34
ORGANISATION/ICT/02/01/34 PROJECT IMPLEMENTATION MONITORING ...................................... 161
35 ORGANISATION/ICT/02/01/35 PROJECT CLOSURE, SIGN-OFF AND RETENTION OF PROJECT

DOCUMENTATION ....................................................................................................................................... 165
36
ORGANISATION/ICT/02/01/36 PROJECT DOCUMENTATION AND RETENTION .................................. 168
37
ORGANISATION/ICT/02/01/37 QUALITY ASSURANCE AT ACQUISITION ............................................ 170
38
ORGANISATION/ICT/02/01/38 QUALITY ASSURANCE AT INSTALLATION/IMPLEMENTATION ........... 174
39
ORGANISATION/ICT/02/01/39 RESEARCH & DEVELOPMENT ............................................................ 177
40
ORGANISATION/ICT/02/01/40 TRAINING ......................................................................................... 181
41
ORGANISATION/ICT/02/01/41 WEB APPLICATION DEVELOPMENT, HOSTING AND CONTENT ............ 184
42
ANNEXES ............................................................................................................................................. 187
43 ORGANISATION/ICT/02/01/ANNEX 1 - CONTINGENCY PLAN FOR LABORATORY INFORMATION

SYSTEMS(LIS), HEALTH INFORMATION SYSTEMS(HIS) .................................................................................. 188
44
ORGANISATION/ICT/02/01/ANNEX 2- SOFTWARE BUSINESS CASE VALIDATION................................. 202
45
ORGANISATION/ICT/02/01/ANNEX 3 - SOFTWARE REQUIREMENTS DEFINITION ................................ 206
46
ORGANISATION/ICT/02/01/ANNEX 4 - SOFTWARE SECURITY REQUIREMENTS DEFINITION ................ 209
47
ORGANISATION/ICT/02/01/ANNEX 5 - SOLUTION DESIGN .................................................................. 222
48
ORGANISATION/ICT/02/01/ANNEX 6 - DEVELOPMENT & CUSTOMISATION........................................ 226
49
ORGANISATION/ICT/02/01/ANNEX 7 - SEPARATION OF DEVELOPMENT AND OPERATIONAL FACILITIES

231
50
ORGANISATION/ICT/02/01/ANNEX 8 - SYSTEM ACCEPTANCE TESTING ............................................... 234
51
ORGANISATION/ICT/02/01/ANNEX 9 - CONTINGENCY PLANNING ...................................................... 237
52
ORGANISATION/ICT/02/01/ANNEX 10 - SECURITY INCIDENTS ............................................................ 244
53 ORGANISATION/ICT/02/01/ANNEX 11 - INCIDENT LOGGING / IDENTIFICATION AND PROTECTING

EVIDENCE..................................................................................................................................................... 247
54
ORGANISATION/ICT/02/01/ANNEX 12 - CONTAINMENT OF INCIDENTS .............................................. 249
55
ORGANISATION/ICT/02/01/ANNEX 13 - ESCALATION OF INCIDENTS TO DISASTER MANAGEMENT .... 254
56
ORGANISATION/ICT/02/01/ANNEX 14 - ERADICATION OF INCIDENTS ................................................ 257
57
ORGANISATION/ICT/02/01/ANNEX 15 - INCIDENT RECOVERY ............................................................ 259
58
ORGANISATION/ICT/02/01/ANNEX 16 - EVALUATION OF INCIDENT REPORTS .................................... 262
59
ORGANISATION/ICT/02/01/ANNEX 17 - INCIDENT CLOSURE ........................................................... - 265 -
60
ORGANISATION/ICT/02/01/ANNEX 18 NEW USER FORM ............................................................. - 267 -
61
ORGANISATION/ICT/02/01/ANNEX 19 DELETION OF ACCOUNT FORM ........................................ - 269 -
62
ORGANISATION/ICT/02/01/ANNEX 20 CHANGE MANAGEMENT FORM ....................................... - 271 -
63
ORGANISATION/ICT/02/01/ANNEX 21 COMPUTER EQUIPMENT PURCHASE/REQUISITION FORM ... 274
64 ORGANISATION/ICT/02/01/ANNEX 22 - CODIFICATION FRAMEWORK FOR ICT GUIDELINES AND

PROCEDURE MANUAL.................................................................................................................................. 276
65
ORGANISATION/ICT/02/01/ANNEX 23 - PROJECT DOCUMENTATION TEMPLATE ................................ 279
66
ORGANISATION/ICT/02/01/ANNEX 24 - ICT SOPS TERMS OF REFERENCE MAPPING ........................... 284
67
ORGANISATION/ICT/02/01/ANNEX 25 - INFORMATION SHARING GUIDELINES................................... 295
Table of figures
FIGURE 1: NETWORK CONFIGURATION FLOWCHART ......................................................................................................... 30
FIGURE 2: SUPPORT AND MAINTANCE FLOW CHART ......................................................................................................... 34
FIGURE 3: HARDWARE FLOWCHART .............................................................................................................................. 39
FIGURE 4: PHYSICAL SECURITY AND ENVIRONMENTAL CONTROLS FLOWCHART .................................................................... 100
FIGURE 5: CHANGE APPROVAL BOARD RISK MATRIX ...................................................................................................... 105
FIGURE 6: NORMAL CHANGE MANAGEMENT FLOWCHART ............................................................................................. 108
FIGURE 7: EMERGENCY CHANGE PROCESS FLOWCHART ................................................................................................... 109
FIGURE 8: GENERAL SOFTWARE GUIDELINE FLOWCHART ................................................................................................. 123
FIGURE 9: ICT QUALITY MANAGEMENT FLOWCHART ..................................................................................................... 128
FIGURE 10: INCIDENT MANAGEMENT PROCESS ............................................................................................................. 134
FIGURE 11: INCIDENT MANAGEMENT FLOWCHART ........................................................................................................ 136
FIGURE 12: INCIDENT MANAGEMENT FLOWCHART ........................................................................................................ 136
FIGURE 13: CONTINGENCY PLANNING FLOWCHART ........................................................................................................ 140
FIGURE 14: DEFINING IT GOALS AND ENTERPRISE ARCHITECTURE FOR IT ........................................................................... 146
FIGURE 15: ICT PROJECT MANAGEMENT FLOWCHART ................................................................................................... 154
FIGURE 16: ICT PROJECT CONCEPTUALIZATION AND APPROVAL FLOWCHART ...................................................................... 157
FIGURE 17: ICT PROJECT PLANNING FLOWCHART .......................................................................................................... 160
FIGURE 18: PROJECT IMPLEMENTATION MONITORING FLOWCHART .................................................................................. 164
FIGURE 19: PROJECT CLOSURE, SIGN-OFF AND RETENTION OF PROJECT DOCUMENTATION FLOWCHART ................................... 168
FIGURE 20 : QUALITY ASSURANCE AT ACQUISITION FLOWCHART ...................................................................................... 173
FIGURE 21 : QUALITY ASSURANCE AT INSTALLATION/IMPLEMENTATION FLOWCHART ............................................................ 175
FIGURE 22: RESEARCH & DEVELOPMENT FLOWCHART .................................................................................................... 180
FIGURE 23 : CONTINGENCY PLANNING SCENARIOS......................................................................................................... 196
FIGURE 24: SOFTWARE BUSINESS CASE VALIDATION FLOWCHART ..................................................................................... 205
FIGURE 25: SOFTWARE REQUIREMENTS DEFINITION FLOWCHART ..................................................................................... 207
FIGURE 26: SOFTWARE SECURITY REQUIREMENTS DEFINITION FLOW CHART ....................................................................... 221
FIGURE 27: SOLUTION DESIGN FLOWCHART .................................................................................................................. 225
FIGURE 28 : DEVELOPMENT & CUSTOMISATION FLOWCHART........................................................................................... 230
FIGURE 29: SEPARATION OF DEVELOPMENT AND OPERATIONAL FACILITIES FLOWCHART ....................................................... 233
FIGURE 30: SYSTEM ACCEPTANCE AND TESTING FLOWCHART ........................................................................................... 236
FIGURE 31: CONTINGENCY PLANNING FLOWCHART ........................................................................................................ 243
FIGURE 32: SECURITY INCIDENT FLOWCHART ................................................................................................................ 246
FIGURE 33: INCIDENT LOGGING / IDENTIFICATION AND PROTECTING EVIDENCE FLOWCHART................................................... 249
FIGURE 34: CONTAINMENT OF INCIDENTS FLOWCHART ................................................................................................... 252
FIGURE 35: ESCALATION OF INCIDENTS TO DISASTER MANAGEMENT FLOWCHART................................................................. 255
FIGURE 36: ERADICATION OF INCIDENTS FLOWCHART ..................................................................................................... 258
FIGURE 37: INCIDENT RECOVERY FLOWCHART ............................................................................................................... 261
FIGURE 38: EVALUATION OF INCIDENT REPORTS FLOWCHART ........................................................................................... 263
FIGURE 39: INCIDENT CLOSURE FLOWCHART ............................................................................................................. - 266 -
Tables
TABLE 1:DATA CENTER OPERATION CHECKLIST .............................................................................................................. 199
Acronyms
CIRT
Computer Incident Response Team
EAPHLNP
East Africa Public Health Laboratory Networking Project
ECSA-HC
Central and Southern Africa Health Community Secretariat
ICT
Information and Communication Technology
ICTSOPs
Information Communication Technology Standard Operating

Procedures and Guidelines Manual
LAN
Local Area Network
Organisation
East Africa Public Health Laboratory Network Project
OS
Operating System
PBX
Public Branch eXchange
WHO
World Health Organisation
Definitions
Abuse of Privilege:
When a user wilfully performs an action prohibited by

organizational Guideline or law, even if technical controls are
insufficient to prevent the user from performing the action.
Backup:
Copy of files and applications made to avoid loss of data and

facilitate recovery in the event of a system crash.
Change:
any implementation of new functionality
any interruption of service
any repair of existing functionality
any removal of existing functionality
Change Management:
The process of controlling modifications to hardware, software,

firmware, and documentation to ensure that Information
Resources are protected against improper modification before,
during, and after system implementation.
Computer Incident Response Team (CIRT): Personnel responsible for coordinating the
response to computer security incidents in an organization
Custodian:
Guardian or caretaker; the holder of data, the agent charged

with implementing the controls specified by the owner. The
custodian is responsible for the processing and storage of
information. For mainframe applications Information Services is
the custodian; for micro and mini applications the owner or user
may retain custodial responsibilities. The custodian is normally

a provider of services.
Electronic mail system:
Any computer software application that allows electronic mail to

be communicated from one computing system to another.
Electronic mail (email):
Any message, image, form, attachment, data, or other

communication sent, received, or stored within an electronic
mail system
Emergency Change:
When an unauthorized immediate response to imminent critical

system failure is needed to prevent widespread service
disruption.
Firewall:
An access control mechanism that acts as a barrier between

two or more segments of a computer network or overall
client/server architecture, used to protect internal networks or
network segments from unauthorized users or processes.
A computer system that provides computer service for a
number of users.
Host:
Information:
Any and all data, regardless of form, that is created, contained

in, or processed by, Information Resources facilities,
communications networks, or storage media.
Information Attack:
An attempt to bypass the physical or information security

measures and controls protecting an AIS. The attack may alter,
release, or deny data. Whether an attack will succeed depends
on the vulnerability of the computer system and the
effectiveness of existing counter measures
Information Resources (IR): Any and all computer printouts, online display devices,
magnetic storage media, and all computer-related activities
involving any device capable of receiving email, browsing Web
sites, or otherwise capable of receiving, storing, managing, or
transmitting electronic data including, but not limited to,
mainframes,
servers,
personal
computers,
notebook
computers, hand-held computers, personal digital assistant
(PDA), pagers, distributed processing systems, network
attached and computer controlled medical and laboratory
equipment (i.e. embedded technology), telecommunication
resources, network environments, telephones, fax machines,
printers and service bureaus. Additionally, it is the procedures,
equipment, facilities, software, and data that are designed,
built, operated, and maintained to create, collect, record,
process, store, retrieve, display, and transmit information.
Information Security Officer (ISO): Responsible to the IRM for administering the
information security functions within the Organisation. The ISO
is the Organisations internal and external point of contact for
all information security matters.
Information Services (IS): The name of the Organisation department responsible for
computers, networking and data management.
Internet:
A global system interconnecting computers and computer

networks. The computers and networks are owned separately
by a host of organizations, government agencies, companies,
and colleges. The Internet is the present information super
highway.
Intranet:
A private network for communications and sharing of

information that, like the Internet, is based on TCP/IP, but is
accessible only to authorized users within an organization. An
organizations intranet is usually protected from external access
by a firewall.
IT governance :
Is defined as the processes that ensure the effective and efficient

use of IT in enabling an organization to achieve its goals.
Local Area Network (LAN): A data communications network spanning a limited

geographical area, a few miles at most. It provides
communication between computers and peripherals at
relatively high data rates and relatively low error rates.
Offsite Storage:
Based on data criticality, offsite storage should be in a

geographically different location from Organisation that does
not share the same disaster threat event. Based on an
assessment of the data backed up, removing the backup media
from the building and storing it in another secured location on
Organisation Campus may be appropriate.
Owner:
The manager or agent responsible for the function which is

supported by the resource, the individual upon whom
responsibility rests for carrying out the program that uses the
resources. The owner is responsible for establishing the
controls that provide the security. The owner of a collection of
information is the person responsible for the business results of
that system or the business use of the information. Where
appropriate, ownership may be shared by managers of different
departments.
Password:
A string of characters which serves as authentication of a

persons identity, which may be used to grant, or deny, access
to private or shared data.
Portable Computing Devices: Any easily portable device that is capable of receiving
and/or transmitting data to and from IR. These include, but are
not limited to, notebook computers, handheld computers,
PDAs, pagers, and cell phones.
Production System:
The hardware, software, physical, procedural, and

organizational issues that need to be considered when
addressing the security of an application, group of applications,
organizations, or group of organizations
Scheduled Change:
Formal notification received, reviewed, and approved by the

review process in advance of the change being made.
Security Administrator:
The person charged with monitoring and implementing security
controls and procedures for a system. Whereas each

Organisation will have one Information Security Officer,
technical management may designate a number of security
administrators.
Security Incident:
In information operations, an assessed event of attempted

entry, unauthorized entry, or an information attack on an
browsing; disruption or denial of service; altered or destroyed
input, processing, storage, or output of information; or changes
to information system hardware, firmware, or software
characteristics with or without the users' knowledge, instruction,
or intent.
Server:
A computer program that provides services to other computer

programs in the same or another computer. A computer
running a server program is frequently referred to as a server,
though it may also be running other client (and server)
programs.
Strong Passwords:
A strong password is a password that is not easily guessed. It

is normally constructed of a sequence of characters, numbers,
and special characters, depending on the capabilities of the
operating system. Typically the longer the password the
stronger it is. It should never be a name, dictionary word in any
language, an acronym, a proper name, a number, or be linked
to any personal information about you such as a birth date,
social security number, and so on.
System Development Life Cycle (SDLC): a set of procedures to guide the development of
production application software and data items. A typical SDLC
includes design, development, maintenance, quality assurance
and acceptance testing.
Trojan Horse:
Destructive programsusually viruses or wormsthat are

hidden in an attractive or innocent-looking piece of software,
such as a game or graphics program. Victims may receive a
Trojan horse program by email or on a diskette, often from
another unknowing victim, or may be urged to download a file
from a Web site or bulletin board.
Unscheduled Change:
Failure to present notification to the formal process in advance

of the change being made. Unscheduled changes will only be
acceptable in the event of a system failure or the discovery of a
security vulnerability.
User:
An individual or automated application or process that is

authorized access to the resource by the owner, in accordance
with the owners procedures and rules.
Vendor:
someone who exchanges goods or services for money.
Virus:
A program that attaches itself to an executable file or

vulnerable application and delivers a payload that ranges from
annoying to extremely destructive. A file virus executes when
an infected file is accessed. A macro virus infects the
executable code embedded in Microsoft Office programs that

allow users to generate macros.
Web page:
A document on the World Wide Web. Every Web page is

identified by a unique URL (Uniform Resource Locator).
Webserver:
A computer that delivers (serves up) web pages.
Web Site:
A location on the World Wide Web, accessed by typing its

address (URL) into a Web browser. A Web site always includes
a home page and may contain additional documents or pages.
Worm:
A program that makes copies of itself elsewhere in a

computing system. These copies may be created on the same
computer or may be sent over networks to other computers.
The first use of the term described a program that copied itself
benignly around a network using otherwise unused resources
on networked machines to perform distributed computation.
Some worms are security threats, using networks to spread
themselves against the wishes of the system owners, and
disrupting networks by overloading them. A worm is similar to a
virus in that it makes copies of itself, but different in that it need
not attach to particular files or sectors at all.
A system of Internet hosts that supports documents formatted
in HTML (Hyper Text Mark-up Language) which contain links to
other documents (hyperlinks) and to audio, video, and graphic
images. Users can access the Web with special applications
called browsers, such as Netscape, Navigator, and Microsoft
Internet Explorer.
World Wide Web:
1 Organisation/ICT/02/01/02 - INTRODUCTION
1.1 Preamble
The East Africa Public Health Laboratory Networking Project is a regional World Bank
funded Project designed to strengthen laboratories in the region. This is a five-year project
being implemented in five countries, namely Kenya, Rwanda, Tanzania , Uganda and
Burundi in collaboration with the East, Central and Southern Africa Health Community
Secretariat (ECSA-HC), East African Community (EAC) , World Health Organization (WHO),
US Centers for Disease Control and Prevention (US CDC) and the Microsoft Organisation
(USA).
Rwanda has agreed to take a regional lead in expanding use of ICT and promoting PBF
approaches for laboratory services, building on its well-recognized successes in these areas.
Cross cutting ICT innovations will be promoted to improve the quality of laboratory and
surveillance data; facilitate the sharing of information; and promote e-learning and webbased knowledge sharing across countries. Rwanda will: (i) share its tools (e.g. standards
and guidelines, reporting forms, request for proposals); (ii) provide related training, capacity
building, and technical support as well as organize site visits; and (iii) take a lead in
determining the applicability of the PBF approach to public health laboratories and document
and share lessons. Rwanda will also share lessons in MDR-TB as it has been selected by
KNCV (Dutch TB Foundation) and will be supported by USAID to become a center of
excellence for MDR-TB for the Africa region. Through this initiative these ICT SOPs have
been developed to assist in improvement of ICT standards across the East African
Community.
The term Organisation shall be used in this ICT standard operating procedures and
Guidelines to represent the EAPHLNP supported organisations where this manual shall be
used on a day-to-day bases.
The Organisation ICT Environment includes all the computers, servers, monitors, printers,
cables, hubs/switches, software, data, information systems, internet connectivity, emailing,
scanners, modems, mouses, keyboards, laptops, use of external data communications
infrastructure, UPSs, data backups, disaster recovery, antivirus protection, help desk,
software library, manuals library, hardware repairs, internet usage, user log-ons, security
permissions, firewalls, web sites, strategic plans and Guidelines, procedures and standards,
training facilities, data replication, and telephony.
Comprehensive computerization and provision of cost effective, reliable and secure
integrated ICT systems and services across and within departments therefore remains
Organisations ICT mission in the immediate and medium terms. Organisation requires
quality, effective and reliable information systems that provide relevant, accurate and timely
data. The ICT infrastructure and systems ought to be developed, maintained and sustained
through appropriate planning, budgeting, ad-hoc and pro-active maintenance, and User
education
To achieve this intent, Organisation needs to operate in an effectively controlled ICT
environment and adhere to the highest standards in the management and utilization of ICT
systems. The development and maintenance of expensive and complex information and
technology environments the hardware, software, data and human resources, requires
discipline and rigid rules to ensure the existence of the highest levels of consistency and
control. It is for this purpose that Organisation has developed this Information
Communication Technology Standard Operating Procedures, Guidelines and Guidelines
(ICTSOPS).
1.2 Objectives of the ICT Standard Operating Procedures and

Guidelines Manual
This Manual has been developed to govern the development, management and utilization of
the Organizations ICT Systems.
This manual will provide meaningful and complete guidance information to all levels of ICT
operations for their efficient exploitation, supervision, guidance and control; and be used for
reference and support; and as a basis for ICT training.
1.3 Enforcement & Violation

Compliance with the contents herein is mandatory.
Organisation may temporarily suspend or permanently block access to IT services and
resources, prior to the initiation or completion of an investigation, when it reasonably
appears necessary to do so in order to protect the integrity, security, or functionality of
Organisation or other computing resources or to protect the Organisation from liability.
Any Employee or user found to have violated this Guideline might be subject to other
disciplinary actions as stipulated in the Disciplinary and Code of Conduct, Cyber laws of the
country and in the Terms and Conditions of Service. The Organisation may also refer
suspected violations of applicable law to appropriate law enforcement agencies. Violation of
this Guideline may result in disciplinary action which may include termination for employees
and temporaries; a termination of employment relations in the case of contractors or
consultants; dismissal for interns and volunteers; or suspension or expulsion in the case of a
student. Additionally, individuals are subject to loss of Organisation Information Resources
access privileges, civil, and criminal prosecution
The Employee may also be instructed to meet or refund the cost of repair or replacement of
any IT resource misplaced, lost or damaged while in their custody, if it is established that
such damage or loss was out of the employees negligence or irresponsible use. This may
also include circumstances where the insurance companies refuse to pay claims, or vendors
refuse to make warranty replacements/repairs because of the circumstances or details of
damage or loss attributed to the staff.
Organisation may also take action relating to a staff's use of Organisation or nonOrganisation computer resources, whether within Organisation or accessed remotely, when
such behaviour may involve the commission of a crime or other illegal activity, poses a
danger to others or is considered unethical.
1.4 Manual Amendment

This Manual will be dynamic; and will be subject to continuous iterative change based on
experience, knowledge and the evolution of information and communication technologies.
Where there is any change in any aspect of the operations or where the manual no longer
meets the requirements or situations in a particular area, the required amendments shall be
recommended to the Head of the ICT Department
Manual amendments shall be promulgated as approved by the ICTWG. After approval,
amendments will be issued to all manual holders. Each amended page shall show the
appropriate amendment number and date. All changes will be clearly denoted.
When an amendment takes place, a copy of the amendment shall be forwarded to all
manual holders along with the appropriate amendment instructions.
Amendment
instructions shall include a Remove Pages and Insert Pages and Reason for Change
list. The amended text shall be identified by a vertical line in the right hand margin.
When the manual or amendments thereto are superseded, instructions shall be issued to all
manual holders to destroy the superseded copies.
1.5 Codification Framework

The codification process is a process that is designed to manage the ordering of this manual
and the codification process orders the management of the main sections and sub-sections
until up to the last element of the document so that they are easily identified. ISO 97001
uses a hierarchical form of codification.
We propose a codification Framework for
Organisation Documents, based on ISO 97001, in which all documents developed, would be
referenced in the following manner:
[Organisation /UNIT/CATEGORY OF DOCUMENT/NUMBER OF DOCUMENT or NAME]
Level 1: Refers to the Organisation and allows documents to be referenced from outside
Organisation. It makes documents unique to Organisation
Level2: Calls to the Unit within the Organisation and allows documents to be uniquely
referenced within Organisation
Level3: Classifies documents within a unit into sub categories of Manuals, forms, reports,
Guidelines, etc. NOTE: This level will use codes as shown in the Document categories
below.
Level 4: This is the name or number of a given document. This allows documents to be
unique within a given classification. It also allows documents to be versioned since they can
retain the same name but have different version numbers.
2 Organisation/ICT/02/01/02 - Eligibility for ICT

Resources and Services
2.1 Description
This Guideline describes who is eligible to use the Information and Communications
Technology resources. In general all staff are eligible to use ICT resources but this should
be in line with the IT Responsible use Guideline described in this manual
2.2 Objective
The main purpose of this Guideline is to define the eligibility for use of ICT resources. The
general principles that underlie eligibility and Responsible use Guidelines for information
technology are:
Organisation ICT resources are for its core business purposes and must be used in line, and
to achieve its core mandate, vision and mission.
Any use counter to this, or which interferes with core use by others, is unacceptable
Specialized information technology services may require additional authorization, approval,
or separate registration as per the User management and Network Access Guidelines.
2.3 Scope
This Guideline applies to all users of Organisation information technology resources
regardless of affiliation, and irrespective of whether those resources are accessed from
Organisation offices or remote/off-site locations.
2.4 Standard Guidelines

All Organisation ICT resources are provided for Organisation business purposes only.
Access to use Organisation ICT resources is a privilege and not a right, and management
reserves the right to restrict access to any system or resource at any time.
All staff employed by Organisation are eligible for all core information technology services in
accordance with the Organisation's Information Technology Responsible Use Guideline.
This, together with the respective Departmental Manager where the staff works, are
responsible for making a request in writing for user account creation.
Specialized information technology services may require authorization, approval, or separate
registration as required by the administrating unit.
Non-staff members performing Organisation work, including but not limited to Researchers,
Students, Vendors, Service Providers and Consultants may request limited services to
information technology services with authorization from the department responsible for their
supervision. This authorization must be in accordance with Guidelines and other restrictions
as defined by the administrating unit of the service
Eligibility may be restricted by either cancellation or suspension at the discretion of
management
2.5 Responsibility
These are people that are affected by this Guideline.
Roles
All ICT Department Staff
All ICT Resource Users
Responsibility
1.Comply with the ICT SOPs
2. Implement in daily
operations
1. Comply with the ICT SOPs
operations
3 Organisation/ICT/02/01/03 - ICT Responsible Use

3.1 Description
The Organisation encourages the use of electronic communications to share information and
knowledge in support of the Organisation's mission and to conduct Organisation business.
To this end, Organisation supports and provides interactive electronic communications
services and facilities such as telephones, voicemail, electronic mail, electronic publishing
services such as the Internet and end user computing such as desktops and laptops.
This Guideline clarifies the applicability of law and of other Organisation Guidelines to
electronic communications. It also establishes new Guideline and procedures where existing
Guidelines do not specifically address issues particular to the use of electronic
communications
3.2 Objective
This Guideline has been established to:
i.
To ensure compliance with applicable statutes, regulations, and mandates

regarding the management of information resources in the East African
Community Partner States
ii.
To establish prudent and acceptable practices regarding the use of information

resources.
iii.
To educate individuals who may use information resources about their

respective responsibilities associated with such use
3.3 Scope
These regulations apply to:
Users (staff whether permanent, contractual, temporary or trainees) using either personal or
Organisation provided equipment connected locally or remotely to the network of
Organisation. Throughout this Guideline, the word "user" will be used collectively to refer to
all such individuals or groups.
All ICT equipment connected (locally or remotely) to Organisation servers and ICT systems
owned by and/or administered by ICT department of Organisation
All devices connected to the Organisation network irrespective of ownership and all external
entities that have an executed contractual agreement with the Organisation

Users must report any weaknesses in Organisation computer security, any incidents of
possible misuse or violation of this agreement to the proper authorities by contacting the
appropriate management.
Users must not attempt to access any data or programs contained on Organisation systems
for which they do not have authorization or explicit consent.
Users must not share their Organisation account(s), passwords, Personal Identification
Numbers (PIN), Security Tokens (i.e. Smartcard), or similar information or devices used for
identification and authorization purposes

Users must not make unauthorized copies of copyrighted software.
Users must not use non-standard shareware or freeware software without Organisation ICT
management approval unless it is on the Organisation standard software list.
Users must not purposely engage in activity that may: harass, threaten or abuse others;
degrade the performance of Information Resources; deprive an authorized Organisation user
access to an Organisation resource; obtain extra resources beyond those allocated;
circumvent Organisation computer security measures.
Users must not download, install or run security programs or utilities that reveal or exploit
weaknesses in the security of a system. For example, Organisation users must not run
password cracking programs, packet sniffers, or port scanners or any other non-approved
programs on Organisation Information Resources.
Organisation Information Resources must not be used for personal benefit.
Users must not intentionally access, create, store or transmit material which Organisation
may deem to be offensive, indecent or obscene.
Access to the Internet from Organisation owned, home based, computer must adhere to all
the same Guidelines that apply to use from within Organisation facilities. Employees must
not allow family members or other non-employees to access Organisation computer
systems.
Users must not otherwise engage in acts against the aims and purposes of Organisation as
specified in its governing documents or in rules, regulations and procedures adopted from
time to time.
3.5 Responsibility
Roles
Responsibility
All ICT Department Staff
1. Comply with the ICT SOPs
2.Implement in daily
operations
All ICT Resource Users
1.Comply with the ICT SOPs
operations
4 Organisation/ICT/02/01/04 - ICT Standards

4.1 Description
This section is meant to provide guidance on the ICT standards that the organisation should
maintain. It looks at hardware, software and process standards that should be maintained.
The advantage of maintaining systems of similar standards reduces the costs of
maintenance and support.
4.2 Objective
It is the intention of the organisation to ensure that ICT systems are of the highest technical
and operational standards.
It is also important to ensure that all systems are interoperable and integrated.
4.3 Scope
This covers all ICT systems including hardware, software, algorithms, e.g. Compression,
encryption, and processes.

The ICT Department is responsible for the development of ICT technology standards and
advising users and departments on the application standards from time to time.
All ICT Procurements, system development and acquisitions must comply with the IT
Standards and specifications approved by the ICT Department.
All staff shall follow the ICT standard operating procedures and Guidelines as described in
this manual
The ICT Department will continuously review business needs and direction, and develop or
update the necessary IT standards, operating procedures and specifications to match and
meet those needs.
The ICT Departments in conjunction with the ICT Department will also review and
incorporate the IT Industry and statutory standards in order to ensure that the organisation
standards conform to the Industry and market standards and trends.
The ICT department in conjunction with the ICT Department will publish / advise users of
new/updated standards as and when they are realized.
The ICT departments will inspect, test and certify all ICT systems (new or existing), to
ensure that they conform to the set ICT standards.
4.5 Responsibility
These are people that are affected by this Guideline
Department
Head of ICT
All ICT Staff

Internal Audit, Quality Assurance
Role(s)
1. Ensure that standards are
implemented in ICT operation.
2. Monitor implementation of
standards
1. Observe standard implementation
in daily operation
1. Confirm that standard are being
implemented in all operations
5 Organisation/ICT/02/01/05 - Staff Awareness and

Commitment
5.1 Description
These Guidelines provide guidance to staff on what they should or shouldnt do, and the
expected behaviour as they use ICT resources. It is important that the staff is aware of these
Guidelines and procedures. They must also understand that their commitment to the
adherence to these Guidelines is mandatory, and hence they must also take initiative to
ensure compliance.
5.2 Objective
This is to ensure that members of staff are aware of these Guidelines and their obligations to
the conformity to these Guidelines and procedures.
These Guidelines are also an education aid meant to train users on best practices.
5.3 Scope
This applies to all ICT Guidelines and procedures, and any directives from management
regarding ICT usage that may be released from time to time.
The Guideline also covers all Organisation staff that may use ICT resources or may be
affected by ICT resources.

All Organisation staff have shared responsibilities for information and its protection and
therefore must keep abreast of and comply with any changes in Organisation ICT
Guidelines.
Adherence and conformance to these ICT Guidelines and procedures is mandatory.
Organisation Staff must read and understand ICT Standard Guidelines and Procedures
document to enhance awareness.
Staff Must sign the acknowledge form as a sign of commitment to comply with these
Guidelines.
ICT Department and Management reserves the right to update and amend these Guidelines
in accordance with developments in ICT systems, processes and security.
The Department will ensure that all new and existing Organisation Staff are provided with
these ICT Guidelines and procedures. This may be through soft or hard copies or any other
medium that will keep users informed.
Staff should familiarize themselves with the organisations IT Guidelines and the related
responsibilities which thereby arise for their job functions. They must also be clear about the
specific information security measures they are expected to undertake as part of their jobs.
All Organisation Staff are personally responsible for understanding and following ICT
Guidelines, and are personally accountable for the consequences of any security violation
resulting from their failure to observe such Guideline.
All Organisation Staff including staff who may not be organisational staff but are at the site or
laboratory are expected to demonstrate awareness and caution in information security
matters. In turn, Organisation shall identify and provide appropriate Information Security
awareness tools to support this process.
The ICT Department shall be responsible for awareness related campaigns to educate the
users about ICT Standard Operating Procedures and Guidelines and all related awareness
campaign shall be adequately communicated and scheduled for attendance.
5.5 Responsibility
Roles
ICT Department
All Users
Responsibilities
1. Provide Awareness campaign to
users about the ICT SOPs
2. Apply the ICT SOPs in all process
3. Ensure that users a compliant with
the ICT SOPS
1. Shall comply with the ICT SOPs
6 Organisation/ICT/02/01/06 - User Account Management

6.1 Description
User accounts are the means used to grant access to Organisation Information Resources.
These accounts provide a means of providing accountability, a key to any computer security
program, for Information Resources usage. This means that creating, controlling, and
monitoring all computer accounts is extremely important to an overall security program.
6.2 Objective
The purpose of the Organisation User Account Management Guideline is to establish the
rules for the creation, monitoring, control and removal of user accounts
6.3 Scope
The Organisation User Account Management Guideline applies equally to all individuals with
authorized access to any Organisation Information Resources. The scope of this Guideline
includes Organisation computer and telecommunications systems and the employees,
contractors, consultants, temporary personnel and other agents of the state who use and
administer Organisation systems.

All individuals who will use the Organisation applications and/or have access to Organisation
information systems must have their own individual user account.
All accounts created must have an associated request and approval that is appropriate for
the Organisation system or service.

All users must sign the Organisation Computer Account Application and Nondisclosure
Agreement before access is given to an account.
All accounts must be uniquely identifiable using the assigned username.
All default passwords for accounts must be constructed in accordance with the Organisation
Password Guideline.
All accounts must have a password expiration that complies with the Organisation Password
Guideline
System Administrators or other designated staff:
System Administrators are responsible for managing user accounts as per the Organisation
Password Guideline.
6.5 Responsibility
Roles
User
Responsibilities
1. Requests access to the Laboratory
information System/Health Information
system through the use of User
Requisition Template.
2. The User department approves the
request
User Help Desk (UHD)
Authoriser
1.
2.
ICT Department
1.
User Department
1.
1. Reviews and approves user account.

2. Creates the user account and log in
password
Determines access for users to specific
applications and information within
Organisation
Provides guidance to UHD relative to
user access.
Determines and addresses training
requirements
Advises the UHD whenever there is a
change in the employment terms of an
individual that might affect his/her user
account or access level
6.6 Procedure
This Procedure describes the process for establishing user accounts for accessing the
information systems used in Organisation. This includes requesting, approving, creating and
maintaining user accounts for all applications supported by ICT Department. Adherence to
this procedure protects the security, privacy and data integrity issues of information held in
Organisation applications.
Conducting background and security checks of users requesting access to Organisation
applications are and remain the sole responsibility of the Organisation ICT Department.
Users must request access to the system through the use of a User Requisition Template.
The user requisition template must be approved by the User Department head.
User Help Desk (UHD) will approve the users access and determine the users appropriate
level of access or role in accessing the requested application. Where appropriate, UHD will
verify with the party responsible for authorizing the users access. UHD will provide the user
with a user name and a password. The password is set to expire upon initial user log in (This
may vary with the Laboratory information systems/Health information system configuration)
and must be re-established following the password rules established in the password
Guideline guidelines.
Where appropriate, training on the application must be completed prior to being granted
access.
It remains the sole
users access must
personnel, change
employment status
required).
responsibility of the users department to inform UHD when a current

be revoked, limited or modified because of security issues, transfer of
in employment role or responsibility, separation or employment, or
change (i.e., change of employee function hence access no longer
All appropriate Organisation sites will use this procedure for guidance relative to establishing
user accounts to Organisation applications and information systems
7 Organisation/ICT/02/01/07 ICT Assessments (ICT

Audits and Inspection
7.1 Description
The ICT environment will from time to time experience changes in the form of new
technologies in the form of new information systems such as HIS, and LIS, Upgrades to the
information systems and network and configuration changes. At the same time threats that
are internal/external in nature require regular reviews and assessment are conducted to
ensure that the ICT environment has minimum risk levels that can be exploited.
7.2 Objective
The purpose of this Guideline is to provide guidance in the process of performing reviews
and audits in the environment as a countermeasure for protecting the information assets of
the organisation.
7.3 Scope
The Organisations ICT Assessment Guideline shall apply to all the entire ICT environment
Hardware, software, networks and people who use the network.

Managers and supervisors shall ensure that all security procedures within their area of
responsibility are carried out correctly to achieve compliance with security Guidelines and
standards.
Independent Technical Compliance Review & Reporting
Information processing resources and associated documentation must be reviewed
immediately after installation and thereafter on a quarterly basis to verify that they are
compliant with the security Guidelines and standards. Findings and recommendations in the
report shall be communicated to the concerned department personnel for implementation.
EAPHLN information processing resources shall be reviewed by an independent third-party
at least on an annual basis. The findings shall be reported to the ICT Department committee
EAPHLN must conduct audits by competent independent party to ensure compliance with
the information security regulation, Guidelines, procedures, standards and guidelines.
Formal procedures shall be developed for planning and reporting audits and audit findings
and ensuring the implementation of a prompt and accurate remedial action.
Audit requirements and activities involving checks on operational systems shall be carefully
planned and agreed to minimize the risk of disruptions to business processes.
Access to information systems audit tools shall be protected to prevent any possible misuse
or compromise.
The security audit must be conducted yearly to audit the systems by an audit team
commissioned by the ICT Department
7.5 Procedure
Three different types of audits have been developed to support the ICT Assessment
compliance program: documentation review, network vulnerability scan, and field audit. At
the conclusion of any audit, an audit report documenting the findings will be produced.
Submitting entities may be subject to any combination of these three audits and are
requested to define a responsible party (i.e., someone who will assist with all audit activities
and be accountable for all deliverables required by the audit on behalf of the submitting
entity as outlined below). All audits will be conducted in English. Local resources may be
required to assist with language translation in order to properly manage the cost of the audit.
The audits consist of the following components:
Documentation review
This audit will review the documentation referenced in the Self-Assessment. If audited, the
submitting entity will be asked to supply a set of documents which define the information
security program as described in their Self-Assessment. Auditors will then review this
documentation against the Guideline requirements.
The documentation review consists of Pre-Audit and Audit phases:
Pre-Audit - One month before the audit, the audit team will send out an information pack
outlining the process to be followed, what documentation is to be made available for the
audit, and other relevant information. A conference call is then conducted between the audit
team and the responsible party for the submitting entity to answer questions and plan the
audit. The responsible party then prepares and submits the documentation requested.
Audit - The Audit Team reviews the documentation submitted and determines if the
requirements are met for the audited Guideline. The Audit Team will maintain a dialog with
the responsible party during this process and may request clarification or additional
documentation.
Network vulnerability scan
This audit will use industry-standard network tools to perform vulnerability scans of the
selected entitys network infrastructure. Based on a mutually agreeable scope and schedule,
these scans examine the network for potential vulnerabilities. The audit team will coordinate
with the responsible party to avoid any impact to normal operations.
A Network Vulnerability Scan consists of two phases, the network mapping and the
vulnerability scan. During the network mapping phase, the scanner discovers the target
network topology and information systems that are online within the given IP address space.
The audit team will examine the network map to determine if all devices included are in fact
considered in scope for the scan.
Once complete, the vulnerability scan phase will begin during which time the scanner will be
set to programmatically scan all devices within the address space for predefined port ranges.
The scan identifies known vulnerabilities that may allow information leakage, denial of
service or privileged access to the unauthorized user.
Field audit
This audit is the most in-depth and includes a mixture of documentation review and on-site
visits and interviews with selected personnel. It may also include attack and penetration
testing of the infrastructure. Each audit will follow a standard process, which consists of PreAudit and Field Work.
Pre-Audit - One month before the audit, the audit team will send out an information pack
outlining the process to be followed, what documentation is to be made available for the
audit, and other relevant information. The audit team will conduct a workshop session with
each entity being audited. The workshop will help the responsibility party to prepare for the
audit and provide the audit team with the information needed to complete the audit.
Field Work - This stage includes interviews with business and IT personnel, review
documentation, selected attack and penetration testing, and feedback to the responsible
party. The length of the audit will vary with the size and complexity of the submitting entity
and will require spending anywhere from three to eighteen days on location.
Audit findings
Each audit will conclude with the audit team consolidating and documenting their findings in
a formal report. The report is reviewed with the responsible party and may recommend the
enabling of or improvement to security controls to become compliant, e.g. installation of
firewalls or establishing a process. Once the accuracy of the findings is acknowledged by the
responsible party, the formal report is shared , the responsible the Information Security
head and/or Area CIO as appropriate or lead Information Security on in ICT Department.
The entity is responsible for documenting a remediation plan which addresses
noncompliance and identifies the timeline. Based upon this remediation plan, an exception
may need to be filed.
If any verification audit identifies significant areas of noncompliance posing risk to the
organisation, a decision may be made to disconnect a location from the network or reduce
available services in order to help mitigate the risk to the rest of the organisation while
remediation activities are undertaken.
7.6 Responsibility
Roles
ICT Department
ICT Department
Responsibilities
1.Plan for Audit
2.Coordination of the Audit
3.Review the Findings
4. Plan remedial Actions
1. Plan for Audit
2. Coordination of the Audit
3. Review the Findings
4. Plan remedial Actions
8 Organisation/ICT/02/01/08 - Network Configuration

8.1 Description
Organisation network infrastructure is provided as a central utility for all users of
Organisation Information Resources. It is important that the infrastructure, which includes
cabling and the associated equipment such as routers and switches, continues to develop
with sufficient flexibility to meet user demands while at the same time remaining capable of
exploiting anticipated developments in high speed networking technology to allow the future
provision of enhanced user services.
8.2 Objective
The purpose of the Organisation Network Configuration Guideline is to establish the rules for
the maintenance, expansion and use of the network infrastructure. These rules are
necessary to preserve the integrity, availability, and confidentiality of Organisation
information.
8.3 Scope
These regulations apply equally to:
i.
Users (staff whether permanent, contractual, consultants, temporary or trainees)

using either personal or Organisation provided equipment connected locally or
remotely to the network of Organisation. Throughout this Guideline, the word
"user" will be used collectively to refer to all such individuals or groups.
ii.
All ICT equipment connected (locally or remotely) to Organisation servers and

ICT systems owned by and/or administered by ICT department of Organisation
iii.
All devices connected to the Organisation network irrespective of ownership and

all external entities that have an executed contractual agreement with the
Organisation

To provide a consistent Organisation network infrastructure capable of exploiting new
networking developments, all infrastructure installations/deployment must be installed by
Organisation ICT or an approved contractor.
All network connected equipment must be configured to a specification approved by the
Organisation ICT Department and must follow the national ICT standards and Guidelines
and regulations related to connectivity .
All hardware connected to the Organisation network is subject to Organisation ICT
management and monitoring standards.
Changes to the configuration of active network management devices must not be made
without the approval of Organisation ICT.
The Organisation network infrastructure supports a well-defined set of approved networking
protocols. Any use of non-sanctioned protocols must be approved by Organisation ICT.
The networking addresses for the supported protocols are allocated, registered and
managed centrally by Organisation ICT.
All connections of the network infrastructure to external third party networks is the
responsibility of Organisation ICT. This includes connections to external telephone networks.
The use of departmental firewalls is not permitted without the written authorization from
Organisation ICT.
Users must not extend or re-transmit network services in any way. This means you must not
install a router, switch, hub, or wireless access point to the Organisation network without
Organisation ICT approval.
Users must not install network hardware or software that provides network services without
Organisation ICT approval.
Users are not permitted to alter network hardware in any way.
No network equipment or other electronic communication facility may be borrowed, removed
or moved from a designated location, without the explicit permission of the ICT Department
or their representative, as appropriate
No equipment other than equipment designed to be portable and used outside Organisation
can be taken out of the Organisation premises without the explicit permission of the ICT
Department of ICT or their representative, as appropriate. For permission to be granted, the
necessary forms (see annex) detailing the purpose of the removal of the equipment and the
equipment details must be filled by the applicant and countersigned by the appropriate
manager or owner as mentioned above.
8.5 Responsibility
Department
Network Administrators
End User
Role(s)
1. Design Network
2. Configure network according to design
3. Ensure network is configured according to
best practise
1. Shall use the network as set out and
approved by the Network administrators
8.6 Procedure
The following procedure shall be followed in setting up preliminary networks or altering
configurations of existing networks
Determine the purpose of the network you intend to set up and document it accordingly
Determine the network components needed to set up the network (this includes cabling,
servers, routers, switches and other hardware and the software needed)
i.
Determine the addressing schemes and labelling for the components identified in 2
above. If IP addresses are required, get the right one from appropriate authorities
ii.
Draw a detailed network diagram showing the configuration as you intend to set it up.
Highlight the relationship to other existing networks both internal to Organisation
(intranet) or external (e.g. Internet)
iii.
Seek the approval for this implementation through the right change management
processes as defined in this manual.
iv.
Acquire the network components and other items needed for this configuration
v.
Set up the network as required
vi.
Update Network documentation
8.7 Flow Chart

Flowchart to describe the Guideline activities
Figure 1: Network Configuration flowchart
9 Organisation/ICT/02/01/09 - Support and Maintenance

9.1 Description
The Organisation ICT gives support and maintenance to users of their ICT systems.
Maintenance aims at retaining the system in the working state which it was supposed to
have been delivered while in support of any efforts by the ICT depart to enable users
achieve their objectives in the usage of ICT.
Support includes such effort as :Additional training, assisting users in activities which are
would enable them complete their tasks, developing minor reports, modifications and
enhancements, undertaking activities such as upgrades, migration, re-installing software,
trouble shooting, etc.
Maintenance here includes both scheduled, preventive maintenance as well as incidental
maintenance which is ad hoc
9.2 Objective
These Guidelines and procedures provide a framework for an support and maintenance of
ICT services for smooth and efficient ICT Services in which they were initially intended.
They are also meant to streamline the way in which support requests are reported, logged
and resolved.
9.3 Scope
The support and maintenance Guidelines and procedure applies equally to all users
(individuals working for Organisation, including permanent full-time and part-time employees,
contract workers, temporary workers, consultants, contractors and business partners, and
vendors) who access ICT services. That is; Management, Technical and Operational Staff
and Users accessing the system from outside the ICT Department.
The support is for all types of applications and requirements:
i.
Hardware: its fault reporting, usage, preventive and corrective maintenance and
installation
ii.
Office Technology Applications:

configuration and error reporting.
iii.
Telecommunications: connections, installation, configuration fault reporting.
iv.
Running specific applications of the Department:
usage,
installation,
upgrades,
updates,

Valid users: ICT Department shall establish a list of all persons who can call regarding
Maintenance and Support services. Persons outside this list should either be considered for
inclusion or given special lower priority treatment.
Valid items to maintain or support: ICT Department shall establish a list of all items that can
be supported. Items outside the list should either be considered for inclusion or given special
lower priority treatment. (This could be linked to the Configuration Management database or
hardware inventory).
Maintenance and support request form: ICT Department shall prepare a printed form or an
automated form. The latter can be a centralized application, an email form or an intranet web
page. These can be used by users to log in their medium to long term support requests.
9.5 Responsibility
Roles
System Administrators
Responsibilities
1. Ensure that all support activities are
done in a timely manner in
accordance
to
support
and
maintenance plan
2. Carry out all support activities in
accordance
to
service
level
agreements
3. Ensure that support is carried out by
competent and approved personnel
either internally or externally
9.6 Procedure
Each call should be registered or logged on the selected media: printed form, email, intranet
web page, application, etc.
The Maintenance and Support Request form should contain the following data :
i.
Time/Date
ii.
Name of User / Department
iii.
Type of call (To be entered by the user and later modified if need be)
iv.
Description of problem
v.
Priority (To be set by the supporter)
vi.
Expected date for completion (To be set by the supporter)
The Calls should be processed by support staff who can tell which one is to be supported by
which unit. They will then be routed accordingly. During routing, the support person can
enter the receiving partys name on the form. It will be the responsibility of the Support or
Maintenance person to process the Change Request if there is reason to change the
Configuration.
External Maintenance or Support: in case these are to be supplied by Suppliers outside the
Department, it will be the responsibility of the Support person to liaise between the User and
the Suppliers. Suppliers will receive copies of the Request and will act accordingly.
The support person will then review the situation, visiting the user if need be. On completion,
the following is entered on the call form:
i.
Time/Date started processing the call
ii.
Time/Date completed processing the call
iii.
Real problem/ Diagnosis: as the user may have phrased the problem wrongly,
the support person will enter the actual cause or issue of support.
iv.
Action taken/resolution: describes what was done to solve the problem or give
support
Name of support staff
In case the call is being handled by a Supplier, then the Supplier must complete the call and
fill in some of the information above.
9.7 Flow Chart
Figure 2: Support and maintance Flow chart
10 Organisation/ICT/02/01/10 - Hardware
10.1 Description
This Guideline covers all the Organisations computing hardware systems whether or not it is
actively used on the computer network. It is meant to ensure that hardware is acquired,
used, maintained and later disposed of using the proper and authorized Guidelines and
procedures.
10.2 Objective
This Guideline aims to promote standardisation, and consequently a reduction in costs to
Organisation through economies of scale and improved efficiencies, by mandating a number
of hardware standards.
10.3 Scope
The Guideline will apply to all Organisation employees and covers ICT equipment procured
for use in all Organisation environments. It also covers other equipment either donated to
Organisation or not owned by the Organisation but being used for Organisation business or
holding Organisation data.

All Organisation Hardware is to be used for Organisation business purposes only. Personal
use shall only be acceptable after prior express authorization by the ICT Department.
All purchases of new systems or parts replacements, or disposal of old or obsolete
hardware must be made in accordance with the Organisations/Countrys Procurement and
Disposal Guidelines, information security Guidelines, as well as Organisations technical
standards. All requests to purchase hardware must be based on the user requirements
specification document and should take into account long term organizational business
plans.
All equipment acquired for and/or on behalf of Organisation shall be deemed to be
Organisations property and governed by the Financial and Asset management Regulations.
Insurance cover for all ICT equipment may be undertaken at the time of purchase, and
renewed annually.
Organisation Equipment shall be disposed of in accordance with the regulations and
Guidelines governing Procurement and Disposal of Organisation Assets, and the financial
regulations in force.
All ICT equipment is to be managed, maintained and serviced by the ICT Department.
Personal equipment shall not be used on Organisation network or for Organisation business
purpose unless with prior express permission by the ICT Department.
10.5 Responsibility
Departments
ICT Department
Roles
1. Inspect new equipment
2. Develop equipment specifications
10.6 Procedure
The procurement of hardware shall be in accordance with the procurement guidelines.
Ownership and asset registration
i.
All equipment covered by this Guideline document must be asset registered
before first use via Organisations IT Help Desk and with the Asset Register.
ii.
The Head of department will be responsible for forwarding a list of IT equipment

to the IT department as and when they get equipment in their respective areas.
Usage
iii.
Users will be required to sign the Equipment Allocation Form on receipt of

allocated equipment.
iv.
Users will also ensure that proper records, including the IT Inventory Database,
are kept and maintained when equipment is returned, replaced or transferred
between users.
v.
Upon exiting employment with the Organisation, users must over all hardware in
their possession to the their relevant line managers, Human Resources or to the
IT department
Installation
vi.
For reasons of security and support, ICT Support staff must undertake all
installation and initial configuration work for equipment covered by this
document.
Movement of equipment
vii.
Any movement of ICT equipment must be logged in advance with the ICT Help
Desk. Any change of keeper must be logged in advance with the IT Service
Desk. For network and security reasons the uplift and re-connection of nonportable IT equipment without notification is not permitted. The keeper is defined
as the primary user of a piece of IT equipment.
viii.
All requests to take equipment off site must be approved by the relevant Head of
Department and ICT Department, and notified in advance to the IT Service Desk.
ix.
All equipment movement or transfers must have a duly signed/ authorised

Organisation Gate pass.
Suppliers of equipment
x.
Only approved equipment from approved suppliers is used for IT equipment

purchases. A list of suppliers and supported equipment will be regularly updated
and maintained at the Procurement office.
xi.
Vendors supplying equipment must offer Original equipment manufacturer

warranty, and they must demonstrate and prove that they are authorised to offer
and execute such warranty and after-sales support.
Insurance
xii.
The ICT Department will prepare and found a list of all ICT equipment eligible
for insurance
xiii.
The Finance and Accounts Department will provide the book values from the
Fixed Assets Register to be used for insurance.
xiv.
Where eligible, insurance cover shall be undertaken as part of the Asset

Management procedures.
Personal equipment
xv.
Personal equipment is not permitted to be used on the Organisation network,

unless there is prior request by the user, stating the requirement and justification
for use, and express approval from the ICT Department.
xvi.
Use of personal equipment may be restricted to certain areas of the network and
certain network services. This equipment should have up to date anti-virus
software and current security fixes.
xvii.
The owner of the equipment is responsible to ensure they gain authorisation

before use.
Disposal of Equipment:
xviii.
Heads of Departments will periodically or as the need arises present a list of old,
obsolete, faulty or unnecessary equipment in their respective Departments and
Areas to the ICT Department for consideration for disposal.
xix.
The ICT Department will also compile and initiate a disposal request for
equipment that is no longer economical to repair, is obsolete, unnecessary, is no
longer supported by the vendors, has reached Zero book value or whose
existence on the Organisation network poses an information security risk. This
shall be in accordance with the Public procurement and disposal guidelines.
Maintenance & Servicing

xx.
All Computers are to be configured by the ICT department. Only unless the user
needs administrative rights for an authorized program, there should be no
change in configuration of the computer.
xxi.
Organisation Staff need approval from the ICT Department in order to add any
extra hardware to the existing systems in place.
xxii.
Computers added to the Organisation domain must have been done by the
Systems Administrator or authorized personnel.
xxiii.
Laptop users should always turn off their laptops before storing them in the carry
cases.
xxiv.
Liquids should be kept a considerable distance away from computers to avoid

any unforeseen damages.
xxv.
All information system hardware faults are to be reported promptly and recorded
in an IT helpdesk database.
xxvi.
All eligible Organisation computing equipment and other associated hardware

belonging to the Organisation must carry appropriate insurance cover against
hardware theft, damage or loss.
xxvii.
Servicing of Organisation is to be performed by ICT Staff or authorized

contracted external party.
10.7 Flow Chart

Flowchart to describe the Guideline activities
Figure 3: Hardware flowchart
11 Organisation/ICT/02/01/11 - Service Level Management

(Procurement)
11.1 Description
Organisation acquires and uses service of third party system or service providers. These
may include but not limited to Internet and data connectivity service providers, maintenance
and repair services, system configuration and other short / long term service contracts.
This section therefore provides guidance on how internal and external service levels shall be
management.
11.2 Objective
Service level management provides a benchmark and standard of performance that is
expected from internal and external service provides. This is to enhance service availability
and quality, and provide a platform for measurement and appraisal of performance.
11.3 Scope
This relates to and covers all internal and external service provision.
All service providers must have Service level agreement(s) or contracts.

The Organisation, represented by the ICT department shall enter into, and maintain service
level agreements with all service providers.
Service Level agreements shall form a basis for performance appraisal of the respective
providers, and also form a basis for their payment or compensation.
The ICT department shall continuously monitor the Service level parameters and ensure
they dont fall below the agreed standards.
All service level agreement must comply with security Standard Guidelines
The ICT department shall also formulate and monitor internal service levels for systems
availability and Help desk support provision.
All service level agreements or contracts must be drafted in accordance to the procurement
laws of the country and must follow the national procurement guidelines.
If procurement is funded by a donor then the procurement must follow the donor guidelines
for procurement where it is mandatory.
11.5 Responsibility
Department
ICT Department
Role(s)
1. Draft the service level agreement based on
Procurement Department
Legal Department
Users
the user requirement.

2. ensure compliance with service level
agreement clauses for the duration of the
agreements
1. Draft services level agreement in
accordance with procurement regulations.
2. Advise the users department and ICT on
procurement related matters when drafting
the SLAs
1. Review all service level agreement before
they are signed.
2. Provide legal advice in cases where there
are breaches.
1. Contribute specification
2. review of service level agreement
11.6 Procedure
The ICT Department will develop the Service level parameters and draft the general terms
and conditions to be included the contracts for service provision.
The Legal and procurement departments will incorporate the Service level parameters in the
procurement documents and final agreements
The ICT department will monitor the service level agreement performance and generate
monthly reports on the performance of the ICT environment components under service level
agreement.
The ICT department will report and escalate any support problems causing interruptions to
service.
12 Organisation/ICT/02/01/12 - Email
12.1 Description
This
Guideline
defines
and
distinguishes
unacceptable/inappropriate use of electronic mail (email).
acceptable/appropriate
from
With Email, messages can be transferred quickly and conveniently across internal network
and globally via the public Internet. These messages contain information which can be
intercepted, stored, read, modified and forwarded to anyone, and sometimes go missing.
Casual comments may be misinterpreted and lead to contractual or other legal issues.
12.2 Objective
The purpose of this Guideline is to ensure the proper use of Organisations email system
and make users aware of what the organisation deems as acceptable and unacceptable use
of its email system. The organisation reserves the right to amend this Guideline at its
discretion. In case of amendments, users will be informed appropriately
Information resources are strategic assets of Organisation that must be managed as
valuable state resources. Thus this Guideline is established to achieve the following:
i.

regarding the management of information resources
ii.
To establish prudent and acceptable practices regarding the use of email.
iii.
To educate individuals using email with respect to their responsibilities

associated with such use.
12.3 Scope
The Organisation e-mail Guideline applies equally to all individuals granted access privileges
to any Organisation information resource with the capacity to send, receive, or store
electronic mail.
Organisation provides electronic information and communications systems to facilitate the
companies business needs and interests. These systems include individual computers, the
computer network, E- mail, and access to the Internet. This system introduces new
opportunities and new risk exposures for the organisation.
In response to the risks, this Guideline describes Organisation's official practices regarding
Electronic Mail (E-mail) security.
This Guideline applies to all users of the corporate email system of Organisation. The Email
Guideline covers:
i.
E-mail Usage
ii.
E-mail Security Settings
iii.
E-mail Retention
iv.
E-mail Attachments

Users shall not provide any other person with their E-mail IDs and personal passwords.
Email Usage;
The following activities are prohibited by this Guideline for organisations email systems:
i.
Sending email that is intimidating or harassing
ii.
Using email for conducting personal business.
iii.
Using email for purposes of political lobbying or campaigning.
iv.
Violating copyright laws by inappropriately distributing protected works
v.
Posing as anyone other than oneself when sending email, except when
authorized to send messages for another when serving in an administrative
support role.
vi.
The use of unauthorized e-mail software.
All email accounts maintained on the organisations email systems are property of the
Organisation. Passwords should not be given to other people and should be changed once a
month. Email accounts not used for 60 days will be deactivated and possibly deleted.
All sensitive Organisation material transmitted over external network must be encrypted.
All user activity on Organisation Information Resources assets is subject to logging and
review.
Electronic mail users must not give the impression that they are representing, giving
opinions, or otherwise making statements on behalf of the Organisation or any unit of the
Organisation unless appropriately authorized (explicitly or implicitly) to do so. Where
appropriate, an explicit disclaimer will be included unless it is clear from the context that the
author is not representing the Organisation. An example of a simple disclaimer is: "the
opinions expressed are my own, and not necessarily those of my employer."
Individuals must not send, forward or receive confidential or sensitive Organisation
information through non-Organisation email accounts. Examples of non-Organisation email
accounts include, but are not limited to, Hotmail, Yahoo mail, AOL mail, and email provided
by other Internet Service Providers (ISP).
Individuals must not send, forward, receive or store confidential or sensitive Organisation
information utilizing non- Organisation accredited mobile devices. Examples of mobile
devices include, but are not limited to, Personal Data Assistants, two-way pagers and
cellular telephones, smart phones.
In order to ensure compliance with this Guideline, Organisation also reserves the right to use
monitoring software in order to check upon the use and content of emails. Such monitoring is
for legitimate purposes only and will be undertaken in accordance with a procedure agreed
with employees.
Email facility shall be available only to the active employees of Organisation. Consequently,
email access shall be provided to a new employee after he/she has joined the Organisation
employment and will be withdrawn immediately upon termination of employment due to any
reason.
Email facility shall not be made available to any other person, including Organisation
contractors, and any other third party providers.
The usage of the E-mail system is subject to the following:
vii.
E-mail shall be used in compliance with the Information Security Guideline
viii.
All access to electronic messages shall be limited to properly authorized

personnel.
ix.
Personal or non-business use of the corporate email systems shall be regulated
All outgoing E-mails shall include a disclaimer such as This email and any files transmitted
with it are confidential and intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify IT Service desk
All E-mail communication shall be in compliance with Organisation standards regarding
decency and appropriate content. Message content restrictions include:
Organisation information resources shall not be used to transmit or receive statements that
contain any material that is offensive, defamatory, or threatening to others
The corporate email systems shall not be used to communicate statements, messages, or
images consisting of pornographic material, ethnic slurs, racial epithets, or any other
material that may be construed as harassing, offensive, or insulting to others based on race,
religion, national origin, colour, marital status, citizenship status, age, disability, sexual
orientation or physical appearance.
Any statements or comments made via E-mail that could in any way be construed as an
action of Organisation must bear a disclaimer such as These statements are solely my
own opinion, and do not necessarily reflect the views of my employer.
Any user of Organisation Email facilities shall be responsible to safeguard the Organisations
reputation.
Staff shall exercise the same care in drafting E-mails, as they would for any other written
communication that bears Organisations name. Staffs are reminded that any use of E-mail
from the network is easily traceable to Organisation and is likely to be attributed to
Organisation even when a suitable disclaimer is included.
Organisations E-mail system shall not be used to produce or distribute chain mail, operate a
business, or make solicitations for personal gain, political or religious causes, or outside
organizations. Users shall not forward or otherwise propagate, to individuals or groups,
chain letters, pyramid schemes or any other types of data that may unnecessarily consume
system resources or interfere with the work of others.
The following activities are prohibited because they impede the functioning of network
communications and the efficient operations of electronic mail systems:
x.
Sending or forwarding chain letters.
xi.
Sending unsolicited messages to large groups except as required to conduct

Organisation business.
xii.
Sending excessively large messages.
xiii.
Sending or forwarding email that is likely to contain computer viruses.
Each users must only use their own Organisation official E-mail account and must not allow
anyone else access to their account. Also, users are not allowed to use their personal
(unofficial) email accounts for sending official mail.
Users shall not publish or distribute internal mailing lists to any non-Organisation person.
Organisation corporate email systems shall not be used to transmit or receive trade secrets,
copyrighted materials, or proprietary or confidential information.
Any information regarded as confidential including legal or contractual agreements, technical
information related to Organisations operations or security etc. shall not be communicated
through E-mail without additional security measures.
Under no circumstances, information received through unsecured E-mail is to be considered
private or secure. Clear text information in transit may be vulnerable to interception. Secure
communication through E-mail can be ensured only by using encryption and digital
signatures.
Attachments from unknown or un-trusted sources must not be opened. All E-mail
attachments, regardless of the source or content, shall be scanned for Virus/Malicious code
and other destructive programs before being opened or stored on any Organisation
computer system. Personnel shall perform a virus scan on all material that is transmitted to
other users via E-mail prior to sending it.
Users must not send unsolicited bulk mail messages (also known as junk mail or
spam). This practice includes, but is not limited to, bulk mailing of commercial advertising
and religious or political tracts. Malicious E-mail, such as mail bombing, is prohibited.
Users shall not execute any programs that are received via E-mail. Specifically, users must
not install any upgrades or patches received via E-mail.
The information contained in the systems (including computer files, E-mail and, Internet
access logs, etc.) are Organisations property. At any time, with or without notice, this
information may be monitored, searched, reviewed, disclosed, or intercepted by
Organisation for any legitimate purpose, including the following:
xiv.
To monitor performance
xv.
Ensure compliance with Organisation Guidelines
xvi.
Prevent misuse of the Systems
xvii.
Troubleshoot hardware and software problems
xviii.
Comply with legal and regulatory requests for information
xix.
Investigate disclosure of confidential business, proprietary information, or

conduct that may be illegal or adversely affect Organisation or its associates
The mailbox size for each user shall be restricted to a prescribed mailbox sizes. Wherever
possible, the system flashes a warning colour indicator when a users mailbox size
approaches the limit (75% of the upper limit) and further incoming mail will be blocked when
the mailbox size exceeds the defined upper limit.
The size of incoming and outgoing E-mails shall be restricted as per the organisations
regulations
Any emails exceeding the limits defined shall automatically be rejected and a system
message shall be forward to sender, otherwise a change request form shall be filled by the
recipient user should such a mail be of business importance.
E-mail Security Settings
Organisation employees shall not modify the security parameters within the corporate E-mail
system. Users making unauthorized changes to the E-mail security parameters are in
violation of this Guideline.
E-mail Retention
Information (mail messages and attachments) on Organisations E-mail system shall be
backed up on the server and shall be available for recovery for a period of 1 year.
E-mail Attachments
All attachments bigger than 10 MB (Internal) and 5 MB (external) shall be compressed using
file compression utilities and will be limited in combined size by the email size as defined in
the previous section.
Attachments size shall be controlled as per above to prevent excessive use of mail server
storage capacity and bandwidth.
System administrator shall ensure that all incoming and outgoing E-mails and attachments
are scanned for Virus/Malicious code and the system blocks any password protected
attachments that cant be scanned by the anti-virus agent.
12.5 Procedures
E-mail Usage
When a new employee joins Organisation, HR Department shall provide such an employee
with Organisation E-mail Guideline and obtain consent of understanding and adherence to
the Guideline from the employee. The responsibility and the disciplinary actions associated
with violation of these Guidelines shall apply thereafter.
As part of the user access setup process, the system administrator takes the following
actions to grant email access:
i.
Define the email ID and password to be the same as network ID and password
in accordance with the user management and password management
Guidelines.
ii.
Open the email account and setup the mailbox size in accordance with the limits
defined.
iii.
Inform the user that his/her email account has been opened
iv.
Send a copy of email Guideline to the new email account
v.
Assist the user to setup email client on his computer, if required.
On an on-going basis, the ICT department monitors email usage and performs automated
content scanning, spam detection and prevention. Any violations of the Guideline are
immediately reported to the Head of ICT.
Upon termination of employment, HR Department sends an urgent message to Head of ICT.
Immediately the email id shall be deactivated once the employee terminated his/her
employment with the Organisation.
12.6 Responsibility
Roles
All Users
ICT Department
ICT/ Management
ICT Department
Internal
(ICT/Management)
Responsibility
Responsible for complying with this and other
corporate Guidelines at all times. This Guideline also
applies to third party employees acting in a similar
capacity whether they are explicitly bound (e.g. by
contractual terms and conditions) or implicitly bound
(e.g. by generally held standards of acceptable
behaviour) to comply with our information security
Guidelines
responsible for building, configuring, operating and
maintaining the corporate email facilities (including
anti-spam, anti-malware and other email security
controls) in accordance with this Guideline
Responsible for maintaining this Guideline and
advising generally on information security controls.
Working in conjunction with other corporate functions,
it is also responsible for running educational activities
to raise awareness and understanding of the
responsibilities identified in this Guideline
responsible for assisting users with secure use of
email facilities, and acts as a focal point for reporting
email security incidents
Audit is authorized to assess compliance with this and other
corporate Guidelines at any time
13 Organisation/ICT/02/01/13 - Internet Usage

13.1 Description
Use of the internet by employees of Organisation is permitted and encouraged where such
use supports the goals and objectives of the organisation.
However, Organisation has a Guideline for the use of the internet whereby employees must
ensure that they:
i.
comply with current legislation
ii.
Use the internet in an acceptable way
iii.
do not create unnecessary business risk to the Organisation by their misuse of
the internet
13.2 Objective
Thus this Guideline is established to achieve the following:
i.

regarding the management of information resources.
ii.
To establish prudent and acceptable practices regarding the use of the Internet.
iii.
To educate individuals who may use the Internet, the intranet, or both with
respect to their responsibilities associated with such use
13.3 Scope
The Internet usage Guidelines and Procedure applies to all Internet users (individuals
working for the Organisation, including permanent full-time and part-time employees,
contract workers, temporary workers, business partners, and vendors) who access the
Internet through the computing or networking resources of Organisation
The Organisation Internet Usage Guideline applies equally to all individuals granted access
to any Organisation Information Resource with the capacity to access the Internet, the
intranet, or both

Software for browsing the Internet is provided to authorize users for authorised business
and research use only.
All software used to access the Internet must be part of the Organisation standard software
suite or approved by the ISO. This software must incorporate all vendor provided security
patches.
All files downloaded from the Internet must be scanned for viruses using the approved
current virus detection software.
All sites accessed must comply with the Organisation Acceptable Use Guidelines.
All user activity on Organisation Information Resources assets is subject to logging and
review.
Content on all Organisation Web sites must comply with the Organisation Acceptable Use
Guidelines.
No offensive or harassing material may be made available via Organisation Web sites.
Non-business related purchases made over the Internet are prohibited. Business related
purchases are subject to Organisation procurement rules.
No personal commercial advertising may be made available via Organisation Web sites.
Organisation Internet access may not be used for personal gain or non-Organisation
personal solicitations.
No Organisation data will be made available via Organisation Websites without approval by
relevant authority for public consumption.
All sensitive Organisation material transmitted over external network must be encrypted.
Electronic files are subject to the same records retention rules that apply to other documents
and must be retained in accordance with departmental records retention schedules.
Incidental personal use of Internet access is restricted to Organisation approved users; it
does not extend to family members or other acquaintances.
Incidental use must not result in direct costs to the Organisation.
Incidental use must not interfere with the normal performance of an employees work duties.
No files or documents may be sent or received that may cause legal liability for, or
embarrassment to, the Organisation.
Storage of personal files and documents within Organisations Information Resources should
be nominal.
All files and documents including personal files and documents are owned by the
Organisation, may be subject to open records requests, and may be accessed in
accordance with this Guideline.
Internet connectivity presents the Organisation with new risks that must be addressed to
safeguard the facilitys vital information assets. Access to the Internet, by personnel, that is
inconsistent with business needs results in the misuse of resources. These activities may
adversely affect productivity due to time spent using or "surfing" the Internet. Additionally,
the Organisation may face loss of reputation and possible legal action through other types of
misuse
Access to the Internet will be provided to users to support business activities and only on an
as-needed basis to perform their jobs and professional roles. This procedure describes the
processes involved in the request, by employees for internet services and the approval for
such services by the requisite approvers in the ICT department at Organisation.
Internet access is requested by the user or users manager submitting an IT Access Request
form to the IT department along with an attached copy of a signed Internet usage Coverage
Acknowledgment Form
Access to the Internet will be approved and provided only if reasonable business needs are
identified. Internet services will be granted based on an employees current job
responsibilities. If an employee moves to another business unit or changes job functions, a
new Internet access request must be submitted within 5 days.
User Internet access requirements will be reviewed periodically by Organisation departments
to ensure that continuing needs are updated
Having reviewed the requirement, the ICT department shall proceed to grant access to a
user (giving the employee the requisite software, usernames and passwords) and shall
inform the user's manager of this approval
Internet access will be discontinued upon termination of employee, completion of contract,
end of service of non-employee, or disciplinary action arising from violation of this Guideline.
In the case of a change in job function and/or transfer the original access code will be
discontinued, and only reissued if necessary and a new request for access is approved.
All user IDs that have been inactive for thirty (30) days will be revoked. The privileges
granted to users must be re-evaluated by management annually. In response to feedback
from management, systems administrators must promptly revoke all privileges no longer
needed by users
13.5 Responsibility
Change the responsibility list
Role
ICT Department
Users Manager
ICT Help/Service Desk
User
Internal Audit
Responsibility
is responsible for maintaining this Guideline and
advising generally on information security controls.
Working in conjunction with other corporate functions, it
is also responsible for running educational activities to
raise
awareness
and
understanding
of
the
responsibilities identified in this Guideline.
is responsible for building, configuring, operating and
maintaining the corporate email facilities (including antispam, anti-malware and other email security controls) in
accordance with this Guideline.
is responsible for assisting users with secure use of
email facilities, and acts as a focal point for reporting
email security incidents.
is responsible for complying with this and other
Guidelines.
is authorized to assess compliance with this and other
corporate Guidelines at any time
14 Organisation/ICT/02/01/14 - Anti-Virus
14.1 Description
A virus is a piece of potentially malicious programming code that will cause some
unexpected or undesirable event. Viruses can be transmitted via email or instant messaging
attachments, downloadable Internet files, USBs, and CDs. Viruses are usually disguised as
something else, and so their presence is not always obvious to the computer user.
It will also specify how files can get into the trusted network and how these files will be
checked for hostile or unwanted content.
A virus infection can be very costly to Organisation in terms of lost data, lost staff productivity,
and/or lost reputation. As a result, one of the goals of Organisation ICT Department is to provide a
computing network environment that is virus-free
14.2 Objective
. The purpose of this Guideline is to provide instructions on measures that must be taken by
the users to help achieve effective virus detection and prevention
14.3 Scope
This Guideline applies to all computers that are connected to the Organisation network via a
standard network connection, wireless connection, modem connection, or virtual private
network connection. This includes both Organisation-owned computers and personally
owned computers attached to the Organisation network. The definition of computers
includes desktop workstations, laptop computers, handheld computing devices, and servers.
In addition, all e-mail gateway providers must provide malware checking and protection for
email messages processed by the gateway.

All computers attached to the Organisation network or standalone computers or devices
must have standard, supported anti-virus software installed. This software must be active, be
scheduled to perform virus checks at regular intervals, and have its virus definition files kept
up to date.
Any activities with the intention to create and/or distribute malicious programs onto the
Organisation network (e.g. viruses, worms, Trojan horses, email bombs, etc.) are strictly
prohibited.
If a user receives what he/she believes to be a virus, or suspects that a computer is infected
with a virus, he/she must notify the User Help Desk (UHD) immediately. The following
information shall be reported (if known): virus name, extent of infection, source of virus, and
potential recipients of infected material
No user should attempt to destroy or remove a virus, or any evidence of that virus, without
direction from head of UHD.
Any virus-infected computer will be removed from the network until it is verified as virus-free.
The virus protection software must not be disabled or bypassed.
The settings for the virus protection software must not be altered in a manner that will reduce
the effectiveness of the software.
The automatic update frequency of the virus protection software must not be altered to
reduce the frequency of updates.
Each file server attached to the Organisation network must utilize Organisation ICT
approved virus protection software and setup to detect and clean viruses that may infect file
shares.
Each e-mail gateway must utilize Organisation ICT approved e-mail virus protection software
and must adhere to the ICT rules for the setup and use of this software.
Every virus that is not automatically cleaned by the virus protection software constitutes a
security incident and must be reported to the User Help Desk (UHD).
The Organisation virus protection software shall be set to automatically pick updates from
the internet and shall be monitored daily to ensure the latest updates are installed
14.5 Responsibility
Roles
Responsibility
The following activities are the
1) The ICT Department is responsible for
responsibility
of
the
maintaining and updating this Anti-Virus
Organisation ICT Department
Guideline. Copies of this Guideline shall be
made available to all users in an
appropriate forum
2) The ICT Department will keep the anti-virus
products it provides up-to-date in terms of
both virus definitions and software version
in use.
3) The ICT Department will apply any updates
to the services it provides that are required
to defend against threats from viruses
4) The ICT Department will install anti-virus
software on all Organisation owned and
installed desktop workstations, laptops, and
servers.
5) The ICT Department will assist employees
in installing anti-virus software according to
standards on personally owned computers
that will be used for business purposes.
Users
6) Users shall
report all
incidences
suspected to be related to virus infection
14.6 Procedure (Virus Removal Procedures for PC)

Save open files and shut down all open programs.
Disconnect the computer from the network by unplugging the network cable from the back of
the computer.
Download the latest virus scan update file and copy it to a zip disk, memory stick or car\did
in order to copy it onto the computer.
Copy the downloaded file onto the computer and run the update file.
When the anti-virus software has updated run a full scan of the computer the scan should
detect any virus present and remove it. If there are any problems removing the file run the
latest Stinger file. Alternatively, contact the helpdesk for further information.
Now that the computer has been cleaned it can reconnected it to the network, or contact the
helpdesk if the network point has been disabled.
It is good practice at this stage to ensure the latest Microsoft security patches have been
installed on the computer.
15 Organisation/ICT/02/01/15 Back- up
15.1 Description
Backup is a copy of a program or file that is stored separately from the original. These
duplicated copies of data on different storage media or additional hardware resources are
used to restore the original after a data loss event. Backups are used primarily for two
purposes. The most common is to restore small numbers of files after they have been
accidently deleted or corrupted. The second is to restore a state following a disaster.
Backups are not archives and are not a substitute for record retention plans, nor are they, by
themselves, business continuity plans
15.2 Objective
This Guideline defines the backup for computer systems that store State data. These
systems are typically servers but are not necessarily limited to servers. Servers expected to
be backed up include file servers, mail servers, web servers, application servers and
database servers.
This Guideline is to establish the rules for the backup and storage of electronic information at
Organisation.
This Guideline is also designed to prevent the loss of Organisation data in the event of an
equipment failure or destruction
15.3 Scope
This Guideline applies to all Staff, permanent or temporary, and third parties who use ICT
devices connected to the Organisation network or who process or store information owned
by Organisation. All users are responsible for arranging adequate data backup procedures
for the data held on IT systems assigned to them
The back procedures in this Guideline apply to all Network Managers, System
Administrators, and Application Administrators who are responsible for systems or for a
collection of data held either remotely on a server or on the hard disk of a computer. ICT
department are responsible for the backup of data held in Organisation databases
This Guideline applies to:
i.
All employees who create data on the organisations computer systems
ii.
All data owners whose data is maintained on any of our central shared systems
iii.
All mission critical data, collected, generated, processed, stored or transmitted

on the organisations infrastructure

The frequency and extent of backups must be in accordance with the importance of the
information and the acceptable risk as determined by the data owner.
The Organisation Information Resources backup and recovery process for each system
must be documented and periodically reviewed.
The vendor(s) providing offsite backup storage for the Organisation must be cleared to
handle the highest level of information stored.
Physical access controls implemented at offsite backup storage locations must meet or
exceed the physical access controls of the source systems. Additionally backup media must
be protected in accordance with the highest Organisation sensitivity level of information
stored.
A process must be implemented to verify the success of the Organisation electronic
information backup.
Backups must be periodically tested to ensure that they are recoverable. This period shall be
set according to the criticality of the data backed up and the frequency of its change
Signature cards held by the offsite backup storage vendor(s) for access to Organisation
backup media must be reviewed annually or when an authorized individual leaves
Organisation.
Procedures between Organisation and the offsite backup storage vendor(s) must be
reviewed at least annually.
Backup tapes must have, at a minimum the following identifying criteria that can be readily
identified by labels and/or a bar-coding system:
i.
System name
ii.
Creation Date
iii.
Sensitivity Classification [Based on applicable electronic record retention

regulations.]
iv.
Organisation Contact Information
All user information on the servers must be identified and scheduled for back-up in line with
the routine back up procedures based on the sensitivity classification.
All back-up tapes or medial shall be tested post the back-up exercise to confirm that all the
data has been adequately and completely backed up in cases of incremental back up.
All routine server backup shall include server scripts and database scripts to ensure that in
cases on server failure the System Administrators are in a position to restore the server to its
last known good configuration including the data on the server.
Data backup
The ICT department recognizes that the backup and maintenance of the files for all
organisational servers, PCs (including application data files) are critical to the viability and
operations of the organisation. Therefore IT must put in place certain basic standard
practices be followed to ensure that data files are backed up on a regular basis.
Restoration
In-line with business requirements, ICT Department must put in place restoration procedures
and mechanisms and ICT Department shall test the backup & restoration plan to ensure that
the backup operation and media work as expected. The process of backup and restoration
shall be reviewed quarterly;
Regular verification of usability of back-ups;
v.
Security and integrity and accuracy of the stored data; and
vi.
Automated schedule job monitoring and exception reporting
Restoration to the production and test environment will be formerly requested for and authorized
to ensure a consistent and predictable computing environment.
15.5 Procedure
Network Server Backups
The servers deployed in the Organisations Network have a backup tape device attached to
the server, or have access to a backup tape devices attached to another server in the local
network. The type of backup tape device varies with the model of the server and the volume
of data to be backed up.
Backup software on the network server is used to control the backup processes (e.g.
Windows NT Backup for Win Servers);
i.
Organisations ICT Department shall ensure all backups are completed

successfully and review the backup process on all network servers daily.
ii.
Logs are maintained to verify the success backup process
Daily backups
iii.
The Logs shall be retained for a period of 7 days and be over-written on the 8th
day
Backup Contents
The contents of the backups vary with the server and location. The primary data that will be
backed up are:
Data files:
iv.
Transactional data, document files (like Word, Excel, PowerPoint, PDF, HTML
etc. and Images.)
v.
E-Mail data for all email accounts located on our E-Mail server.
vi.
User files on the servers on dedicated folders
System Data:
vii.
Applications files for the server and other selected software installed on the
server.
viii.
Server Scripts and logs including database scripts and logs
Daily Backups
ix.
Backups of data on production servers will occur every business day at 8:00PM
x.
Backup of the satellite labs environment on the branch servers will occur every
business day after end of day processes.
Tape Rotation and incremental back ups

To reduce backup tape costs and to promote an efficient and reliable backup, the following
schedule is defined for the Organisations server backup tape rotations:
xi.
Daily backups (Monday Sunday) take place on a 1-week rotation; tapes overwritten on the 8th day
xii.
Monthly full backups of servers occur on the last day of every month and these
tapes shall not be rotated;
xiii.
Special backups may be made for longer retention periods before or after
system upgrades, major business projects, or for financial reporting periods.
xiv.
Tapes preceding service disruption events (such as power failures that could
lead to data loss, transaction stripping) shall be isolated and treated as special
backups for longer retention periods.
xv.
Incremental backup will be taken on the same cartridge at least twice a week.
Offsite Storage of tapes

xvi.
Daily backups for days other than the current day will be stored in the safe at the
server room.
xvii.
Monthly Backups: Monthly backups for all network locations will also be moved
to an offsite location for long-term storage. The retention period for the monthly
tapes is as follows:
xviii.
A monthly backup will be kept for each month, for each server for a period of at
least 5 years.
Documentation and Tracking

xix.
All backup media and tape drives shall be appropriately labelled;
xx.
A tape transfer log shall be appropriately signed off by staff responsible for
migration of the backup media to the organisations off-site storage location;
15.6 Responsibility
Roles
Responsibilities
ICT Department
doing the backups or delegating
checking that they have been

successfully completed
recording the information on the

backup sheets
ensuring that the backups are

stored securely
ensuring that the tapes are

properly labelled and rotated
advising the ICT Department on

requirements for new tapes
15.7 Procedure
Below are guidelines of procedures and responsibilities for defined information and
communications technology (ICT) employees (i.e., system administrators, network
administrators). These guidelines will include a backup strategy that applies to the following:
i.
Computerized systems that store source or original Organisation information.
ii.
Implement standard frequency and type of backup for each type of computer
system or platform in use based on the significance of the information and its
frequency of change.
Backups should occur on a daily basis or be based on the significance of the information and
its frequency of change. A preferred method of backup is disk-to-disk backup. If this method
is not applicable for the system, then tape backup is required.
Back up all necessary data files and programs to recreate the operating environment.
Implement procedures for transferring a recent copy of backup media to a physically and
environmentally secure off-site storage location. An inventory and tracking system must be
maintained. Ensure that the following are stored at the off-site storage location:
iii.
Source and object code for production programs
iv.
Master files and transaction files necessary to recreate the current master files
v.
System and program documentation
vi.
Operating systems, utilities, and other environmental software
vii.
Other vital records
Ensure that documented procedures exist for the recovery and restoration of information
from backup media.
Identify I.T. staff responsible for ensuring successful back-ups.
Routinely copy operating software, application software, and production information to
backup media based on frequencies set by management. This applies to major systems
(e.g., local area network (LAN) or wide area network (WAN) servers, client/server database
servers, special-purpose computers) in use
Maintain at least three generations of backup media, i.e. grandfather, father, son
arrangement for operating and application software.
Define data model to be used for each type of data; i.e. full + incremental, full + differential,
(for file servers) or database exports or extracts (for applications)
Back up of the printed documentation and pre-printed forms necessary for recovery. Convert
printed documentation and pre-printed forms into electronic format and move them into the
DR site.
Test the backup to determine if data files and programs can be recovered
16 Organisation/ICT/02/01/16 - ICT System Access Control

16.1 Description
Information is a valuable asset and significant damage can be the result of lost Organisation
confidential information, patient information, or personally identifiable information. As a
result, Organisation must appropriately protect information and comply with any regulatory
and legislative requirements governing information security.
This Guideline defines the rules necessary to achieve this protection and to ensure a secure
and reliable operation of Organisation information systems.
16.2 Purpose
To control access to information and information systems and to only provide access to
those who need it based upon a business requirement to perform their duties and functions.
This Guideline ensures that only authorized users are granted access to information
systems, and users are limited to specific defined, documented and approved applications
and levels of access rights.
16.3 Scope
This Guideline applies to entire information technology assets (computers and servers)
operating in Organisation and is intended for use by all Organisation employees, contract
workers or others who use the IT resources of Organisation, collectively termed User.
Users have responsibility to safeguard access to Organisation information assets that has
been entrusted to them. Each User shall be uniquely identified, properly authenticated and
properly authorized as required.

Business Requirement for Access
i.
All persons or entities shall be uniquely identified, authenticated, logged, and

authorized before access is granted to Organisation information and systems.
ii.
All access privileges shall be denied unless explicitly authorised and

documented by the owner of the information asset.
iii.
Access privileges shall be granted only to the minimum level required by the
users role, on principle of need-to-know and need-to-do basis in accordance
with users job responsibilities, business and security requirements.
iv.
The owner of the information resources and business application shall review the
access rights periodically (at least every six months.) for unused, redundant, or
expired user accesses or accounts, or incorrect privileges. Special attention
should be given to privileged access rights which allow users to override system
controls.
v.
A formal record of all registered users shall be maintained by the ICT

Department and checked periodically (at least every six months) for unused,
redundant, or expired user accesses or accounts, or incorrect privileges.
vi.
The ICT Department shall ensure that such mechanisms prevent unauthorised
personnel, remote connections and other system (network) entry ports from
accessing computer resources and minimize the need for authorised users to
use multiple sign-ons.
vii.
Procedures must be defined for secure account distribution.
User access management

viii.
There must be a formal user registration and de-registration procedure for

granting and revoking access to all information systems and services.
ix.
Provide all users with a unique identifier (user ID) for their personal use only and
use a suitable authentication technique to substantiate the claimed identity of a
user.
x.
Restrict administrator and/or operator privileges to individuals on the basis of

legitimate business need.
xi.
Restrict access to privileged functions to explicitly authorized personnel.
xii.
Strictly limit access rights, particularly those of temporary staff and contractors,
to a need-to-know basis that permits access only to the systems and resources
that are required for them to perform their duties.
xiii.
Use a secure log-on procedure to control access to information systems.

Procedures must be defined for the allocation of passwords (both permanent
and temporary) to users in a secure and confidential manner in compliance to
the password Guideline.
xiv.
Perform regular reviews of access controls and rights to all systems with
consideration given to level of sensitivity of the information processed by and
stored on the system.
xv.
Restrict access or connectivity to the Organisation network, business

applications or information systems to the required services and systems.
xvi.
Separate user functionality from information system management or processing

functionality
xvii.
Users must inform the ICT Department that they are to provide appropriate
protection (e.g., termination of active sessions, log-off from information systems,
activation of a screen saver, and preventing unauthorized access) of unattended
equipment.
xviii.
Users must be provided a written statement of their access privileges and verify
that they understand and agree to the conditions of access evidenced by their
signature.
xix.
The use of removable media within the Organisation environments is specifically

prohibited unless as authorized by both line management and IT security
management and strictly for work related tasks.
16.5 Responsibility
Roles
ICT Department
All staff
Responsibilities
ICT Department of Organisation shall be
responsible for communicating and ensuring
compliance with this Guideline and its
supporting guidelines and procedures.
Additionally managers and Directors of
Organisation shall provide guidance and
decisions regarding granting and removing
access to Organisation information and
systems.
All Organisation related people (employees,
suppliers, trade, channel, and joint venture
partners) who are in possession of, or
control access to Organisation information
or systems covered by this Guideline shall
be responsible and accountable for its
protection in accordance with this Guideline,
supporting standards and procedures, and
any applicable national laws.
16.6 Procedures
Procedures addressing user access should cover all stages in the life-cycle from
initial registration of new users to de-registration once access is no longer required. The
Access control procedure at a minimum, shall consider adequate mechanisms for:
i.
Roles and responsibilities in the Access Management process;
ii.
Appropriate approvals and authorisation for granting access;
iii.
Timely action relating to requesting, establishing, issuing, suspending and

closing of user accounts;
iv.
Modifying account parameters; and
v.
Periodic Management review and reporting
User Identification procedures

vi.
Each user of Organisations information services will have a uniquely assigned
User ID to enable individual authentication and accountability.
vii.
For Organisation employees, documented authorization from both the

employee's supervisor/ and Human Resources is required for the User ID be
issued or revoked.
viii.
For non-Organisation staff (e.g. contractors), documented authorization from

their Organisation supervisor is required for the User ID to be issued and
revoked.
ix.
For external business partners using Organisation controlled extranet services,

the external business partner authorizes the issue and revocation of their User
IDs for their staff
x.
A generic User ID that is designated for use by either multiple users or

anonymous users, without enabling individual authentication and accountability,
is not allowed. Exceptions to this Guideline require the documented approvals
from both the owner of the information-related asset or business process, and
from the IT Security Manager.
xi.
All contract workers User IDs shall have an automatic termination date
consistent with the negotiated contract dates.
Granting Access Privileges procedures

xii.
The owner of information, an information-related asset, or a business process is

responsible for authorizing access privileges to the respective resource, and for
documenting who has access to the resource.
xiii.
The authorizing party will verify that the type of access requested is appropriate
for the users role and responsibilities.
xiv.
Users are provided a written statement of their access privileges and verify that
they understand and agree to the conditions of access.
xv.
Contractors and non-Organisation staff are subject to the Organisation Code of

Business Conduct.
xvi.
Contractors and non-Organisation staff, provide written acknowledgement of

their compliance to the Code of Business Conduct before access privileges are
granted.
xvii.
No access privileges are granted until the respective authorization procedures

have been completed
Revoking Access Privileges procedure

xviii.
Upon change of a users employment status or role within Organisation (e.g.

transfer, promotion, termination), owners of the information-related assets and
business processes are notified by Human Resources.
xix.
Access privileges are immediately revoked or reassigned (if appropriate) upon

notification from HR.
xx.
Where the termination date is known, as in the case of temporary workers or

contractors, the respective access privileges will have an automatic termination
date, where possible, consistent with the negotiated contract dates
Maintenance of Access Privileges procedure

xxi.
Owners of information-related assets or business processes perform regular

reviews of user access privileges for their respective systems to identify and
remove invalid users and accounts.
Privileged Access Management

xxii.
Administrative or similar privileged access to system level resources is for the

exclusive use of personnel performing system maintenance and related
administrative duties.
xxiii.
Privileged access is used only for system administrative tasks where such
access is required. Non-administrative tasks are performed through standard
user identities and privileges.
xxiv.
Privileged access is reviewed regularly to identify and remove invalid users and
accounts
Initialization of Passwords
xxv.
xxvi.
Access identifiers and their associated credentials (e.g. passwords) are

considered confidential information and are managed in a secure manner to
prevent their disclosure during the initial set up of the user account. At a
minimum, the following controls are applied:
Initial passwords determined by the system, rather than by the user, are
communicated to the user in a different medium than the one used by the
system (i.e. a password for a system account is provided to the user by their
manager, rather than electronically through email messaging.)
xxvii. Initial or temporary passwords are changed immediately upon their first use
Remote access procedure
xxviii.
Controls should be in place to provide reasonable assurance that remote access

connections are identified and reported centrally and that they are controlled by
dual factor authentication (two different types of authentication are necessary
e.g. password and security token).
Use of highly privileged IDs and utility programs / access to source code
xxix.
The use of privileged IDs and utility programs should be restricted to a

few exclusively restricted authorised IT personnel who require them specific
defined, documented and approved support duties and responsibilities.
Access to program source code should be limited to authorised personnel only.
Compliance statements
xxx.
Users who have access to Organisations Information systems must sign a

compliance statement prior to issuance of a user ID. Annual confirmations will be
required of all system users.
Confidential Systems monitoring

xxxi.
Access to confidential systems

minimum collect information on:
will
be
logged
and
audited
and
at
a. Access time
b. User account
c. Method of access
xxxii.
All privileged commands must be traceable to specific user accounts
xxxiii.
Audit trails for confidential systems should be backed up and stored in
accordance with Organisations back-up and disaster recovery plans.

xxxiv.
All system and application logs must be maintained in a form that cannot readily
be viewed by unauthorized persons.
xxxv.
All logs must be audited on a periodic basis. Audit results should be included in
periodic management reports.
Access for non-Employees:

xxxvi.
Individuals who are not employees, contractors, consultants, or business

partners must not be granted a user-ID or otherwise be given privileges to
use Organisations computers or information systems unless the written
approval of the Department Head has first been obtained.
Unauthorized Access:
xxxvii.
Employees are prohibited from gaining unauthorized access to any other

information systems or in any way damaging, altering, or disrupting the
operations of these systems. System privileges allowing the modification of
production data must be restricted to production applications.
Screen savers
xxxviii. Staff must make use of password protected screen savers or lock workstation
utility when PCs and terminals are left unattended and still connected to
the network or accessing applications.
17 Organisation/ICT/02/01/17 - Removable media

17.1 Description
Removable media is a well-known source of malware infections and has been directly tied to
the loss of sensitive information in many organizations. This Guideline is intended to minimize
the risk of loss or exposure of sensitive information maintained by Organisation and to reduce
the risk of acquiring malware infections on computers operated by Organisation.
Removable media examples include flash drive, external hard disk, storage devices of phone,
floppy disks, compact disc (read only and rewriteable)
17.2 Purpose
This Guideline aims at putting in place a framework for the handling and usage of removable
media in order to protect the information resource of Organisation. It is not meant to limit the
usage of such media but rather to enhance the safety of such usage
17.3 Scope
This Guideline covers the usage of removable media on all computers and servers operating
in Organisation.

The use of removable media within the Organisation environments is specifically prohibited
unless as authorized by both line management and ICT security management and strictly for
work related tasks. Organisation staff may only use Organisation removable media in their
work computers.
Organisation removable media may not be connected to or used in computers that are not
owned or leased by Organisation without explicit permission of the Organisation IT Security
management staff.
Sensitive information should be stored on removable media only when required in the
performance of your assigned duties or when providing information required by other state
agencies.
When Sensitive information is stored on removable media; it must be encrypted in
accordance with the Organisation Acceptable Encryption Guideline. Exceptions to this
Guideline may be requested on a case-by-case basis by Organisation - exception
procedures.
In cases were the organisation uses software for authentication of removable media all users
shall use the software to protect files from removable media where files are exchanged using
removable media.
17.5 Responsibility
Roles
System Administrator
Responsibilities
1.Ensuring that users comply with the
removable media guidelines
2. Shall consistently monitor the
network for removable media related
risks.
Users
3. Shall provide awareness to the users

on risks associated with removable
media
1. Shall comply with the removable
media guidelines and procedure.
2. shall report any removable media
identified risk on their computers to ICT
department
18 Organisation/ICT/02/01/18 - Network Access

18.1 Description
The Organisation is committed to ensuring that its internal networks and information
resources are adequately protected against any threats from external or internal sources that
could disrupt Organisation operations or gain unauthorised access to Organisation
information.
Users shall only be provided with access to network services that they have been specifically
authorized to use.
For network access through applications or systems, there shall be a formal registration
procedure. This procedure should allow granular user access control to the network and
network resources. In addition removal of access rights should also be a simple one-step
process to protect Organisations services at the end of an employees employment
18.2 Purpose
To enable Organisation control all connections to its networks in order to preserve the
private nature of the Organisation's network and computing facilities
18.3 Scope
Network Access scope entails the following guidelines; The scope of these controls should
also be extended to allow only authorised access between the separate internal IT systems
within Organisation.

Authentication for Inbound Connections: Authorized external sources or users outside of the
Organisation network are appropriately identified and authenticated before their session
connected into the Organisation network.
Authentication for Outbound Connections: Network connections made from the Organisation
network to an external network node for purposes that may expose Organisation to
significant business risk (e.g. electronic business transactions), the external network
destination with which the transaction is to be made is identified and authenticated.
Remote Diagnostic Port Protection: Only the network ports documented as necessary for
business operations are to be opened. Ports that permit remote access for administrator or
diagnostic use are high risk and must have appropriate security mechanisms to prevent
unauthorized access.
Open ports shall be authorized and documented by the owner of the information-related
asset or business process.
Segregation in Networks: Segments of the Organisation network must be logically separated
to help ensure the segregation of incompatible duties and access privileges of users, both
internal and external to Organisation. In consideration of access control Guidelines, access
requirements, and risk assessments, the Organisation network is divided into appropriate
domains or zones. As applicable, these zones include:
i.
Application development
ii.
Operations
iii.
Extranet services
iv.
Network perimeter
Network Connection Control: The access capabilities of users connecting across the shared
network are limited to only those capabilities defined by their user privileges. Services,
whose degree of access is determined by the nature of the users network connection, are
identified, documented, and their access controlled. These services may include:
v.
Network applications, such as email
vi.
File transfer facilities
vii.
Interactive access (e.g. command line)
Network Routing Control: The network routing from a users access point to the users
intranet destination ensures that the users network traffic remains within the network
segments and nodes for which the user has been authorized to use. The controls to achieve
this include, but are not limited to:
viii.
Disablement of unlimited network roaming.
ix.
Definition of logical domains to isolate segments of the network and the

implementation of security gateways (e.g. firewalls) control traffic between logical
domains.
x.
Pre-defining the users network path in the applications, to prevent any user
intervention and eliminate the opportunity to explore the network.
Security Network Services: The owner of a network system or device is aware of its security
features and limitations. Appropriate measures shall be implemented to manage the risk of
the assets security limitations.
xi.
The security features and limitations of the asset are reviewed and documented
before the asset is deployed into production.
xii.
The asset is kept up-to-date with its respective patches and updates.
Concurrent network sessions: User access to the network shall be limited to only single login
session on the network. Multiple concurrent login sessions from more than one computer
terminal connected on the network is strictly prohibited and shall be enforced.
Internal Network Areas
xiii.
Internal network areas must be securely managed in order to preserve the

private nature of the Organisation's internal network areas.
xiv.
All networks and network equipment must have a nominated owner and a
nominated management authority.
xv.
Groups of similar sub-networks may be aggregated to form a defined network

partition with uniform security requirements.
xvi.
Sub-networks with specific security requirements and characteristics must be

identified and recorded.
xvii.
Security gateways must be implemented between network partitions to maintain

the different security characteristics of both partitions.
xviii.
Network connectivity access control must operate at least on a sub-network (or

LAN to LAN) basis.
xix.
Automatic network configuration, routing/switching updates or network service

advertisement must operate under the same access controls and by their
operation must not compromise those controls.
xx.
Network access control mechanisms must be implemented by access

lists/closed user Groups/filters/proxies at an interface level or across all protocols
to prevent communications other than those necessary between authorised
domains.
xxi.
Tunnel end points are security gateways unless the networks at both ends have
identical security requirements and characteristics and must comply with the
Organisation's standards.
Network management
xxii.
Network services, remote and external connections to the network

(including diagnostic ports) should be centrally controlled and the access
privileges provided should be limited to those services required for business
purposes.
xxiii.
All network logons should require a unique user ID and password to

ensure that only authorised users gain access to the network.
xxiv.
Network management must be partitioned into common administrative domains

with segregated control of sensitive management operations.
xxv.
Segments of the Organisation network shall be logically separated to help

ensure the segregation of incompatible duties and access privileges of users,
both internal and external to Organisation. In consideration of access control
Guidelines, access requirements, and risk assessments, the Organisation
network shall be divided into appropriate domains or zones.
xxvi.
Management of a device must not offer the capability to introduce traffic through
that device to any connected end point.
xxvii.
Network management systems must be established so that devices (or agents

within devices) can only be managed or re-configured by authentic and
authorised management systems.
xxviii.
The devices/agents must cryptographically authenticate the source of all

management commands that can affect the configuration of the network.
xxix.
The devices/agents must check if the management system is authorised to

perform those actions.
xxx.
The management protocol must ensure the integrity and, where appropriate,
privacy of all management commands and responses.
xxxi.
Dynamic (automated) routing/switching/configuration updates must only take

place amongst authorised and authentic devices/agents.
xxxii.
Formal documented processes must be established for managing remote

network equipment.
xxxiii.
Mechanisms must be provided to protect the confidentiality and integrity of

management information passing over public networks.
xxxiv.
Mechanisms and processes to maintain the availability of network services and

remote connection must be established.
xxxv.
In the absence of strong cryptographic connection authentication, an attempt to

detect routing and switching conflicts caused by rogue or mis-configured devices
must be made.
xxxvi.
Backbone core networks must include appropriately placed probes to detect illicit
addresses or protocols as determined necessary by risk.
xxxvii.
Detection of illicit addresses/protocols/traffic must be treated as a security

breach and must be reported
Wireless Network Areas

xxxviii. Wireless connections are broadcast beyond the boundaries of Organisation's
perimeter and must be managed accordingly to ensure that internal wireless
networks are indeed internal and that third party wireless networks are treated
with the same level of control as the Internet.
xxxix.
All wireless connection to the Organisation's network must be strongly

authenticated at the point of connection using at least token-based methods.
xl.
WEP must not be relied upon for transport integrity and confidentiality. The risk
to desktop devices visible on broadcast wireless networks must be managed
using WPA, anti-virus software and personal firewalls origination/destination
address.
xli.
All wireless LAN connection to Organisation's network must occur via an

encryption tunnelling protocol (e.g. IPsec VPN) established between remote
wireless NIC/workstation and the connection gateway.
xlii.
All new applications of wireless connection directly to the Organisation's network

must be approved by Organisation ICT Security Manager.
xliii.
A central register of all Organisation wireless LANs must be maintained.
xliv.
All third party wireless networks must be treated as the Internet and appropriate
controls must be applied.
Gateway Management
xlv.
A central register of all public and third-party network connectivity must be

maintained by Organisation ICT Department.
xlvi.
All access to Organisation networks from public or third-party networks must only
take place through approved and authorised secure network gateways.
xlvii.
Connectivity with Organisation's network must be categorised and a structured

scheme for the provision of secure network gateways must be devised
xlviii.
Each distinct external connection to a business service must be subject to

approval by the business owner and Organisation Security Manager.
xlix.
Firewalls must perform proxy and address translation functions that will hide the
Organisation's network addressing structure and other directory information,
except for that which is required to support the service permitted by the firewall.
l.
Organisation Perimeter Network channels must be configured to hide the

network addressing structure using network address translation.
li.
All access through an external channel must ensure that TCP/IP connections are
staged via a proxy device in each De-militarized Zone.
lii.
The proxy device must be configured to forward the communication by

establishing a new onward TCP/IP connection.
liii.
A secure network gateway must only permit inbound connectivity to authorised

destination network addresses.
liv.
All data transfers with third parties must, where feasible, be initiated by
Organisation systems.
lv.
Information flows into the Organisation must be initiated by the Organisation

('pulled onto Organisation systems'), where feasible, rather than initiated
('pushed') by an external source.
lvi.
A secure network gateway must only permit through connectivity for authorised
services/protocols to authorised destination network addresses.
lvii.
By default firewalls must be configured to prohibit any connectivity or any

protocols that are not explicitly permitted.
lviii.
Permitted connectivity and protocols must be explicitly defined and documented

in an evolving Organisation technical security standard.
lix.
Applications must be restricted to using a limited and defined range of ports for
connectivity through firewalls.
lx.
Permitted firewall connectivity must explicitly define source, destination, protocol

and protocol port using the principle of allowing the least access possible to
achieve the required functionality.
lxi.
Networks supporting multiple business applications or extending across

organisational boundaries must incorporate routing controls.
lxii.
Routing controls must be based on the aggregated access control requirements

of the connected systems.
lxiii.
Routing controls must include controls to check the source and destination of
management traffic.
lxiv.
Organisation Perimeter Network channel, where possible, must be configured to

detect and filter out malicious code and other unauthorised software or
undesirable content.
Traffic Isolation
lxv.
Controls must be provided to preserve the confidentiality and integrity of the

Organisation's information carried by third party networks.
lxvi.
Connections over public/shared routed (e.g. IP) networks must take place over
encrypted Virtual Private Network tunnels.
lxvii.
Connections over public/shared connection-oriented (e.g. Frame Relay, X.25,)

must take place within defined Closed User Groups.
Connections to Boundary Gateways

lxviii.
The ability to make network connections must be controlled to ensure that the
external end of the connection is known.
lxix.
Authentication may not be required where the Organisation has physical

knowledge or control of the end point.
lxx.
detect duplicate addresses on ports must be made e.g. intruder detection on

network switches or hubs.
lxxi.

detect routing and switching conflicts caused by rogue or mis-configured devices
must be made.
lxxii.
In the absence of strong cryptographic connection authentication, any means of

device authentication provided on particular protocols/devices must be used e.g.
PPP challenge/handshake protocol (CHAP) at the data link layer.
lxxiii.
The external connection must always be authenticated.
lxxiv.
All connections, sessions, or virtual circuits must only be established after a

cryptographic authentication phase which mutually authenticates source and
destination.
lxxv.
For connectionless services, the authentication requirements must be fulfilled at

the nearest higher protocol layer where a connection exists (e.g. IP shifts the
connection authentication requirement to TCP).
lxxvi.
Detected violations or failure of authentication must logged as a security event in

the nearest network device, be raised as a security alarm and investigated.
lxxvii.
Indirect access to Organisation systems and networks via public or third-party

network points of presence (e.g. public X.25 PAD, public network operators
TCP/IP PoP, etc.) must be authenticated at a secure network gateway
connecting the two networks.
lxxviii.
Unattended remote access connections to Organisation systems and networks

(i.e. dial backup of devices, dynamic ISDN connection of small office routers)
that occur without user intervention must use a cryptographic handshake for
authentication to establish the session (e.g. PPP CHAP) with appropriately
managed keys/secrets.
lxxix.
Where the other end of the connection is a single responsible user (e.g. dial up
or VPN), user authentication is sufficient where the Organisation can ensure that
the connection is only to that user, from only one workstation and that the
workstation is under Organisation control.
lxxx.
Individual access must be from personal computers with up to date anti-virus

software and personal firewalls.
Organisation firewall requirements

lxxxi.
Firewall protection will provide a point of defence and a controlled and audited
access mechanism for all internal or external accesses to the
Organisations network. This audit access should be sufficient to detect breaches
of firewall security and attempted network intrusions.
lxxxii.
All traffic between the internal network and external access points must pass
through an authorised firewall.
lxxxiii.
All traffic within the different internal networks must be kept logically separate.
lxxxiv.
Firewalls will allow only authorised traffic through as documented in approved

security access rules.
lxxxv.
All firewalls must be configured to be secure from unauthorised electronic or
physical access attempts.

lxxxvi.
All firewall configuration and security Guideline rules must be documented,

maintained and retained in a secure location that can be accessed by only
appropriately authorised officers.
lxxxvii. The default condition of the firewall should be to deny all connections to and
from the network. Only explicitly authorised connections should be allowed.
lxxxviii. All non-essential networking and system services must be eliminated or removed
from the firewall.
lxxxix.
The firewall should be configured to support the anonymity of the internal IT

networks through network address translation. This means the sending
machine within the IT network has its address in the outbound IP packets
substituted with that of the firewall address.
xc.
Tight controls and close monitoring processes are to be applied to the on-going
management of an installed firewall, so that at any point in time it can be verified
that the firewall is effectively fulfilling its intended purpose. The verification of the
firewall integrity should be done at least once a month.
xci.
Firewall audit logs must be reviewed for firewall security breaches and attempted
network intrusions on a daily basis.
xcii.
A mechanism and process shall be in place so that Organisation is notified if

vulnerabilities are discovered (e.g. notified by vendor or relevant security
vulnerability mailing lists) in the firewall software and so that these vulnerabilities
are addressed within three working days.
xciii.
Firewall software will be regularly updated.
18.5 Responsibility
Roles
All User
ICT Department
ICT Department
Responsibility
Responsible for complying with this and other
Guidelines
responsible for building, configuring, operating and
maintaining the corporate network and enforcing
security controls in accordance with this Guideline
responsible for assisting users with secure
connections to the network
19 Organisation/ICT/02/01/19 - Third Party Network Access

19.1 Description
A non-Organisation organization given access to the Organisation enterprise introduces risk.
Although the non-Organisation organization may be controlled by its own security Guidelines
and procedures, its Guidelines and procedures may not be fully appropriate for
Organisations unique regulatory, contractual, and business requirements.
19.2 Purpose
The purpose of this Guideline is to provide security guidelines that will govern
implementation of all third party connections made to or from the Organisation network to
ensure that connections between Organisation systems and networks and public switched
networks are permitted via secure network gateways.
19.3 Scope
A third party connection is any connection between Organisations network and a foreign
network owned by another person/Organisation not related to Organisation.
Within the scope of this Guideline, third party connections will refer to the following: Remote
Access via Dial In, Internet Remote Access, Website Administration and Maintenance,
Extranet, Internet Service Usage, WAN, LAN to LAN, Virtual Private Network (VPN

Where access to Organisation IT systems and resources is required by organizations
external to Organisation, the risks of granting such access must be identified and controlled.
Authorization for third party access into the Organisation network requires that a risk
assessment be performed on the third party connection
Controls to address the identified risks and how Organisation information technology assets
affected by the access shall be protected are documented in a contract with the third party.
The contract, at a minimum, addresses:
i.
All parties involved with the outsourcing agreement, including subcontractors,

are made aware of their security responsibilities.
ii.
The relevant legal and regulatory requirements of the organisation.
iii.
The physical and logical security controls used by the outside party to control
access to Organisations information assets are specified by the outside party
and approved by the appropriate Security Manager.
iv.
The processes used by the outside party to protect the availability, integrity and
confidentiality of Organisation s information assets are specified by the outside
party and approved by the appropriate Security Manager.
v.
Organisation reserves the right to audit the contractual responsibilities of the

parties involved with the outsourcing agreement.
vi.
Controls are established to restore Organisation information assets to their

original state upon termination of the access agreement. This will also cover the
destruction of sensitive information no longer required.

vii.
Reports on performance, system faults, and security incidents are provided to

Organisation, as needed.
viii.
Reasonable access for testing or review will be available to Organisation
The third party is granted the minimum degree of access required for its designated and
authorized purposes.
Vendors must not have access to the production environment unless explicitly authorised by
the ICT Department.
Organisation reserves the right to audit the activities and practices of the third partys access
Third parties connecting to or using Organisation facilities, systems, or data, comply with the
relevant Organisation security Guidelines and standards, as determined by the Security
Manager, before access is granted.
The Security Managers are responsible for the review and authorization of third party access
requests.
The third party is bound to conduct its business with Organisation consistent to
Organisations degree of ethical standards and professional conduct.
Third Party Administration of Access to Systems
ix.
Suppliers to Organisation that provide application based services that handle

Organisation information must control access to these applications in compliance
with Organisation ICT Guideline and procedures manual.
x.
All the requirements of Guideline regarding access control processes must be

applied to third-party administration of access to applications and systems.
xi.
Where third-parties are engaged in administering access to applications and

systems, authorisation of access must be provided by designated Organisation
authorisers rather than supplier personnel.
xii.
The supplier of third-party access administration to applications must

contractually commit to only granting access once proper authorisation has been
obtained.
xiii.
The supplier of third-party access administration to applications must provide

Organisations designated authorisers with a regular monthly report of currently
authorised users of the applications.
xiv.
All the requirements of Guideline regarding authentication of access must be

xv.
All the requirements of Guideline regarding granting of access rights must be

xvi.
All the requirements of Guideline regarding the monitoring of security and user
activity as well as the reporting and escalation of suspected or actual security
breaches must be applied to third-party administration of access to applications
and systems.
xvii.
The supplier of third-party access administration to applications must provide

contractual assurances that no Organisation information or functionality can be
accessed by other parties, including other customers or the supplier.

Third-Party Support Access to Organisation Systems
xviii.
Suppliers to Organisation that support services, products and applications

installed and operated within Organisation and consequently need access
(remote or direct) to Organisation systems must comply with the ICT Guidelines
and procedures manual at all times and such access must be closely monitored
by Organisation.
xix.
Formal documented procedures must be produced to control third-party access

to Organisation systems, including the authorisation of access, creation of
accounts and distribution of authenticators, enabling and disabling of accounts,
monitoring of access activities and termination of access.
xx.
The third-party and all its staff or agents engaged in the access must be
contractually bound to comply with the requirements of Organisation ICT
Guidelines and procedures manual.
xxi.
The access must be authorised by the relevant business owner(s). Where

access is repeated by the same third-party staff or agent, the authorisation need
only be granted once.
xxii.
Connections to systems must be from Organisation owned workstations and

locations, or where determined necessary by Organisation Information Security,
from third-party workstation(s) that are isolated from other networks. Third-party
workstations must be built to comply with Organisation standard builds to
preserve security and operability.
xxiii.
Where a third-party is to be granted remote access to Organisation systems, the

third-party standalone workstation from which access is initiated must be
physically secured by the supplier, with only individuals authorised to connect to
Organisation systems having access to the workstation.
xxiv.
Where third-parties are given access to Organisation systems from a third-party

workstation, the workstation must have a copy of the Organisation preferred antivirus software installed, using the latest release of virus pattern files/scanning
engine at all times.
xxv.
Where third-parties are given support access to the Organisation system that is
Internet connected, static IP addresses must be used for the third-party or
Organisation workstation so that network connectivity controls via IP address
filtering (such as at the Organisation 's firewall) can be maintained as granular as
possible.
xxvi.
Where third-parties are given support access to the Organisation system

containing CONFIDENTIAL information, including personal data in various legal
and regulatory jurisdictions, controls must be established and monitored to
prevent the third-party transferring information to other computers outside the
Organisation.
xxvii.
Where a third-party is to be granted access to Organisation systems, each staff

or agent must be issued with an individual account on the target system. These
accounts must be enabled when required and disabled when not required.
xxviii.
Where a third-party is to be granted remote access to Organisation systems,
each staff or agent session must be authenticated using strong authentication

via hardware tokens.
xxix.
Where a third-party is to be granted remote privileged access to Organisation

systems, the staff or agent's individual accounts must be enabled for the
duration of the session only, then disabled until the next use.
xxx.
Where a third-party is to be granted remote access to Organisation systems, the

remote connectivity must employ the Organisation's preferred secure remote
connectivity method.
xxxi.
Where third-parties are given access to Organisation systems, suitable access

control must be applied to minimise the risk that a third-party could gain
unauthorised access to systems if they attempted to. These controls should, as a
minimum, include minimisation of command line access to third-party accounts
and reduction of privileges assigned to third-party accounts.
xxxii.
The contract governing the service must include an undertaking that none of
their staff or agents will access or attempt to access any system other than that
which they are contracted to support.
xxxiii.
All commands issued by third-party staff or agents during access to Organisation

systems must be logged (where technically feasible) and monitored to ensure
that Organisation staff can inspect the activity of the third party.
xxxiv.
The logs showing the activities undertaken during third party access to the
Organisation system must be reviewed by the appropriate IT manager on
completion of the access and any unexplained activity discussed with the thirdparty immediately.
xxxv.
Where unauthorised or inappropriate activity is suspected during a third-party

support session to the Organisation system, it must be escalated to ICT
Department, Organisation IT Security Management and third-party management
immediately.
xxxvi.
All system logs used to record activity on the system must be secured against
access by the third-party.
xxxvii.
Any changes made to Organisation systems during third-party access for

support purposes must have been previously subject to formal change control
and proper authorisation by designated Organisation change approvers.
Third-party Application Service or Hosting

xxxviii. Suppliers to the Organisation that install and operate applications or other
systems as part of a service to the Organisation and consequently control the
security of those systems must comply with relevant parts of Organisation
Information Security Guideline.
xxxix.
Where a third-party is to provide application or system services or hosting for the

Organisation, the service must first undergo a formal risk analysis that seeks to
confirm the suppliers ability to comply with Organisation IT Guidelines and
procedures manual and to identify controls under Guideline that form specific
security requirements for the service. This process is called Supplier Security
Qualification (SSQ).
xl.
The provision of third party application or system services or hosting to the
Organisation must be approved by the Organisation IT Security manager or a

nominated deputy before deployment, based on the results of an SSQ.
xli.

Organisation, the supplier is wholly responsible for ensuring that all security
processes and mechanisms, including those specified in Guideline, are in place
before the production use of the application or service.
xlii.

Organisation, the supplier is wholly responsible for ensuring the secure operation
of the service and any information it supports in compliance with Organisation
Information Security Guideline.
xliii.

Organisation, the Organisation may, at its discretion, separately monitor the
security of the service being provided in addition to the supplier's own
monitoring, and will instruct the supplier to remedy and any deficiency
encountered.
xliv.

Organisation, the supplier must monitor security related events in the service
and fully investigate any incidents, reporting status to the Organisation
throughout.
xlv.
Where a third-party is to provide application or system services or hosting for

Organisation and the related infrastructure (server, connectivity, communications
equipment, etc.) is situated on the Organisation's network, the service must first
undergo a detailed security inspection and vulnerability scan prior to transfer to
production. This applies even if the related infrastructure is segregated from the
Organisation's network by a single-tier firewall, but does not apply if the
infrastructure is Internet-connected and situated outside a full Organisation
firewall.
xlvi.

Organisation and the related infrastructure is situated on a third-party network,
the service must first undergo a detailed security inspection and vulnerability
scan prior to transfer to production if the application or system service is
classified as CRITICAL.
xlvii.

Organisation, and a pre-production security inspection and vulnerability scan has
been conducted in accordance with Guideline, all the issues raised during the
inspection and scan must be remedied by the third-party prior to the service
entering production.
xlviii.

Organisation, all changes to the application, service and associated
infrastructure must be managed using a documented change control process
with appropriate sign-off by the relevant business owner.
xlix.

Organisation, all changes to the security aspects of any application, service and
associated infrastructure must be approved by Organisation Information Security
as well as the relevant business owner.
l.

Organisation, and the application or service is classified as CRITICAL, all the
requirements of Guideline regarding the security mechanisms necessary to
protect information must be satisfied by the application or service, especially the
use of encryption to protect information transferred over networks, the use of
firewalls to protect Internet facing hosts, the secure configuration of web servers,
and the use of strong user authentication for remote sessions to the hosts.
li.

Organisation, the third-party supplier must continuously monitor for new security
vulnerabilities that may affect the components of the application or service and
must implement the relevant patches or fixes for those vulnerabilities on a timely
basis and in accord with the agreed change control process, after suitable
testing.
lii.
Organisation critical third party hosted systems must be segregated from other
organisation's systems as determined by risk. Third parties must not enable
connectivity between Organisation systems and other organisation's systems
19.5 Responsibility
Roles
ICT Department
Contractor/ Vendor/ Visitor
Responsibility
Ensuring compliance with this Guideline and ensuring
that third party connections are vetted and approved
before they are accepted
It is the responsibility of each vendor or contractor to
ensure all external third party connections initiated
from within or remotely to Organisations local / wide
area network are secure, approved by ICT department
and do not expose the network to any threats that
compromise the confidentiality, availability and
integrity of Organisation data and information.
20 Organisation/ICT/02/01/20 - Password
20.1 Description
Security is an on-going responsibility, and appropriate measures must be taken on a regular
basis to ensure compliance and monitor effectiveness. Passwords are an important aspect
of computer security. They are the front line of protection for user accounts. A poorly chosen
password may result in the compromise of Organisations entire corporate network. As such,
all Organisation employees (including contractors and vendors with access to Organisation
systems) are responsible for taking the appropriate steps, as outlined below, to select and
secure their passwords.
20.2 Purpose
The purpose of this Guideline is to establish a standard for creation of strong passwords, the
protection of those passwords, and the frequency of change.
The application of these password rules and guidelines will ensure appropriate protection of
Organisation assets.
The effectiveness of this Guideline is entirely dependent upon passwords remaining
confidential at all times.
20.3 Scope
The scope of this Guideline applies to all systems and personnel who have or are
responsible for an account (or any form of access that supports or requires a password) on
any system that resides at any Organisation facility, has access to the Organisation network,
or stores any non-public Organisation information.
Should it be impossible to implement these specifications on a particular system, this must
be reported to security management.

Passwords are a primary means to control access to systems and should therefore be
allocated, selected, used and managed in a manner designed to protect against
unauthorized discovery or usage.
A password should be viewed as ones own personal key to gain access to the electronic
data stored at Organisation. Since all information must be treated as confidential as a basic
principle, it is not permissible to share password information with another person.
Passwords must be kept confidential at all times. This is the responsibility of the password
owner.
20.5 Responsibility
Roles
ICT Department
Responsibility
Ensure that all user accounts have passwords on
them and the Guidelines governing password creation,
Roles
All Users
Responsibility
change and expiry are enforced
It is the responsibility of each user to adhere to the
guideline provided in this Guideline and to ensure
conformity to the set rules on password creation and
usage, avoiding sharing of passwords or writing them
down on papers for remembrance
20.6 Procedures and Guidelines

Password allocation
i.
The identity of a user must be verified prior to providing a new, replacement, or

temporary password using defined procedures. User forgotten passwords may
be replaced or recovered using a challenge or question /response process.
ii.
Passwords must be given to users in a secure manner which limits the potential
for unauthorised interception.
iii.
The use of shared accounts is only permissible in exceptional cases and only
after consultation with IT security management and explicit approval of the ICT
Department.
iv.
In principle, all users have standard user authorisation. A higher authorisation

level, local administrator rights, is only permissible in exceptional cases and only
after consultation with IT security management.
v.
Passwords that are signed out, e.g. providing increased levels of access as
part of emergency production systems access must be changed immediately
after use. A record of use must be maintained by the designated owner and
available for audit
vi.
Default vendor password must be changed first time as soon as systems or

software and unpacked and installed. Once the ID becomes operational after
development and testing, the password must be changed again.
Password use
vii.
Passwords must not be recorded (e.g. paper, software file or hand held device)
unless this can be stored securely and the method of storage has been
approved
viii.
Passwords must be changed immediately whenever there is an indication of

possible system or password compromise or revealed due to user account.
ix.
Quality passwords must be selected in conformance with the password selection

rules and guidelines below.
x.
Temporary passwords must be changed at the first logon and after a password
reset.
xi.
Where SNMP is used, the community strings must be defined as something

other than the standard defaults of "public," "private" and "system" and must be
different from the passwords used to log in interactively. A keyed hash must be
used where available (e.g., SNMPv2).
xii.
Passwords must not be included in any automated log-on process, e.g. stored in
a macro script, hard coded scripts, trouble ticket system or function keys unless
this can be stored securely and the method of storage has been approved by the
IT security manager or ICT Department.
xiii.
Passwords must not be inserted into email messages or other forms of electronic
communication.
xiv.
The same password must not be used for Organisation accounts as for other
non- Organisation access (e.g. personal email account, option trading, benefits,
etc.). Where possible, don't use the same password for various Organisation
access needs. For example, select one password for the Finance systems and a
separate password for IT systems.
xv.
Do not share Organisation passwords with anyone, including administrative

assistants or secretaries. All passwords are to be treated as sensitive,
Confidential
Organisation
information.
xvi.
To prevent the potential compromise of multiple systems, the administrator

password must not be reused across multiple systems.
Password management system

xvii.
Systems for managing passwords must be wherever possible interactive and

enforce quality passwords and passwords protection.
xviii.
The system should enforce expiry of temporary passwords after a configurable

period of use.
xix.
Password cracking or guessing may be performed on a periodic or random basis

by IT Security management or its delegates. If a password is guessed or cracked
during one of these scans, the user will be required to change it.
xx.
Every user ID must be allocated a password. There must not be NULL

passwords.
xxi.
Users must be allowed to select and change their passwords. A confirmation

procedure to allow for input errors must be included.
xxii.
Passwords set for system IDs (e.g. to facilitate file transfers or authenticate
background system tasks) do not have to change at regular intervals but in
mitigation of this, password construction must abide by the rules set out for
Administrator Ids as specified in the Password selection rules procedure.
xxiii.
Passwords used for authentication of IDs assigned to individuals must be forced

to change at regular intervals.
xxiv.
Period of validity of passwords should be set to a minimum expiry of 1 day and a

maximum of 90.
xxv.
Administrator passwords must be changed every 45 days (at a minimum).
xxvi.
Passwords must not be displayed in readable text on the screen at any one time,
particularly when being entered.
xxvii.
Passwords must be securely stored by the system in an encrypted format so that

it cant be retrieved or seen by any one (including administrators).
xxviii.
If the password is entered incorrect 5 times, the account will be blocked
xxix.
Successful and unsuccessful attempts to change passwords must be recorded in

system logs.
xxx.
Users must not use the Save Credentials option when logging in to either
applications or web pages.
xxxi.
Passwords which have been used and then changed can only be used again
after 12 password changes. For administrators, this must be at least 13 different
passwords to prevent annual cycles. If this is not possible, then minimum life
duration of 15 days must be enforced by the system to prevent old passwords

from being recycled in a short time.
xxxii.
User accounts that have system-level privileges granted through group

memberships or programs such as "sudo" must have a unique password from all
other accounts held by that user.
xxxiii.
All user-level and system-level passwords must conform to the detailed

password construction rules and guidelines described in section 5.8.4 below.
Password construction selection guidelines

xxxiv.
The minimum password length shall be eight (08) characters.
xxxv.
The password must contain a mixture of at least one character from 3 of the 4
sets of permissible characters described below:
a. Contain a upper and lower case characters (e.g., a-z, A-Z)
b. Numerals 0-9
c. Special characters created
d. Special characters created using the shift function (e.g. &; %, ?; ; $; etc)
xxxvi.
The following sets of characters are not permissible.

a. Portions of the Users name are not permitted
b. Special characters created without using the shift function (e.g. @; #;;etc).
xxxvii.
Good Passwords
a. Good passwords are those that can still be remembered despite the
proscribed guidelines yet which are not difficult to replace at the end of
each 90 day period.
Good practice:
Select a saying like
Humpty Dumpty sat on a wall
This produces the following password
HDsoaw
Break up the character sequence using numbers and/or special
characters:
H%Dsoa&w
xxxviii. Good passwords have the following characteristics:
a. Are at least fifteen alphanumeric characters long and is a
passphrase (No0neHas29Fl0wers).
b. Are not a word in any language, slang, dialect, jargon, etc.
c. Are not based on personal information, names of family, etc.
d. Passwords should never be written down or stored on-line.
e. Try to create passwords that can be easily remembered. One way
to do this is create a password based on a song title, affirmation,
or other phrase. For example, the phrase might be: "This May Be
One Way To Remember" and the password could be: "TmB1w2R!"
or "Tmb1W>r~" or some other variation.
xxxix.
Bad passwords
a. In keeping with the password Guideline, you are obligated to observe a

variety of security precautions when using our computer systems.
Nevertheless passwords can still have weaknesses.
Avoid:
a. Password generations (Stephen1, Stephen2, etc)
b. General terms found in the dictionary (String Ray; Construction)
c. License Plate numbers (RAB634A)
Password Protection Standards and rules
xl.
Don't reveal a password over the phone to ANYONE. This also applies to
enquiries made by IT support
xli.
Don't reveal a password in an email message
xlii.
Don't reveal a password to the boss
xliii.
Don't talk about a password in the presence of a third party (e.g. if an IT

employee is setting something upon your system and a password is needed,
type it in yourself).
xliv.
Don't hint at the format of a password (e.g., "my family name")
xlv.
Don't reveal a password on written inquiry, questionnaires or security forms
xlvi.
Don't share a password with family members
xlvii.
Don't reveal a password to co-workers while on vacation
xlviii.
If someone demands a password, refer them to this document or have them call
someone in the IT security manager.
xlix.
If you want to use personal questions to help you remember your password, so
with care. Bad example: Whats my wifes last name?
l.
Do not use the "Remember Password" feature of applications (e.g., Mdaemon,

Eudora, Outlook, Netscape Messenger).
li.
Again, do not write passwords down and store them anywhere in your office.
lii.
Do not store passwords in a file on ANY computer system (including Black berry
or similar devices) without encryption.
liii.
If you keep a list of password, please keep in mind that this should be stored in a
safe place. As a matter of principle, this information must be stored separately
from the access media used
liv.
Do not choose a name for the list that reveals its contents (e.g. passwordlist.xls).
Use of Passwords and Passphrases for Remote Access Users

lv.
Access to the Organisation Networks via remote access is to be controlled using

either a one-time password authentication or a public/private key system with a
strong passphrase.
Passphrases
lvi.
Passphrases are generally used for public/private key authentication. A

public/private key system defines a mathematical relationship between the public
key that is known by all, and the private key, that is known only to the user.
Without the passphrase to "unlock" the private key, the user cannot gain access.
lvii.
Passphrases are not the same as passwords. A passphrase is a longer version

of a password and is, therefore, more secure. A passphrase is typically
composed of multiple words. Because of this, a passphrase is more secure
against "dictionary attacks."
lviii.
A good passphrase is relatively long and contains a combination of upper and

lowercase letters and numeric and punctuation characters. An example of a
good passphrase:
"The*?#>*@TrafficOnThe101Was*&#!#ThisMorning"
NOTE: All of the rules above that apply to passwords apply to passphrases.
Database password standards
lix.
lx.
lxi.
Storage of Data Base User Names and Passwords

a. Database user names and passwords may be stored in a file separate
from the executing body of the program's code. This file must not be
world readable.
b. Database credentials may reside on the database server. In this case,
a hash number identifying the credentials may be stored in the
executing body of the program's code.
c. Database credentials may be stored as part of an authentication server
(i.e., an entitlement directory), such as an LDAP server used for user
authentication. Database authentication may occur on behalf of a
program as part of the user authentication process at the authentication
server. In this case, there is no need for programmatic use of database
credentials.
d. Database credentials may not reside in the documents tree of a web
server.
e. Pass through authentication (i.e., Oracle OPS$ authentication) must
not allow access to the database based solely upon a remote user's
authentication on the remote host.
f. Passwords or pass phrases used to access a database must adhere to
the Password Guideline.
Retrieval of Database User Names and Passwords
a. If stored in a file that is not source code, then database user names
and passwords must be read from the file immediately prior to use.
Immediately following database authentication, the memory containing
the user name and password must be released or cleared.
b. The scope into which you may store database credentials must be
physically separated from the other areas of your code, e.g., the
credentials must be in a separate source file. The file that contains the
credentials must contain no other code but the credentials (i.e., the
user name and password) and any functions, routines, or methods that
will be used to access the credentials.
c. For languages that execute from source code, the credentials' source
file must not reside in the same browse able or executable file directory
tree in which the executing body of code resides.
Access to Database User Names and Passwords
a. Every program or every collection of programs implementing a single
business function must have unique database credentials.
b. Sharing of credentials between programs is not allowed.
c. Database passwords used by programs are system-level passwords as

defined by the Password Guideline.
d. Developer groups must have a process in place to ensure that
database passwords are controlled and changed in accordance with
the Password Guideline. This process must include a method for
restricting knowledge of database passwords to a need-to-know basis.
21 Organisation/ICT/02/01/21 - Physical Security and

Environmental Controls
21.1 Description
If a malicious individual gains physical access to an information system, it is nearly
impossible to protect that system effectively. Therefore, it is critical that the physical security
surrounding information and information systems, as well as the supporting infrastructure,
e.g. routers, switches, power and environmental systems, be maintained at an appropriate
level.
In addition, effective environmental controls are critical to ensuring the availability and
integrity of the firms information processing systems.
21.2 Purpose
To ensure that ICT take appropriate measures designed to safeguard the physical perimeter
of Organisation facilities that house ICT information assets.
To protect Organisation's computing facilities from physical harm.
To provide guidance in the protection of restricted areas using control technologies to
prevent unauthorized access attempts
21.3 Scope
This Guideline applies to Organisation facilities that physically house information and
technology assets and covers server room access and Health Laboratories, movement of
computer equipment, network cabling and set up of server room. Access control Guideline
shall be applicable to all employees, contractors and visitors.

Physical Security perimeters
i.
Security perimeters (barriers such as walls, card controlled entry gates or

manned reception desks) shall be used to protect areas that contain information
and information processing facilities, taking into account that the facilities may be
shared by external companies.
ii.
Security perimeters shall be clearly defined, and the siting and strength of each
of the perimeters shall depend on the security requirements of the ICT assets
within the perimeter and the results of a risk assessment;
iii.
Suitable intruder detection systems shall be installed to international

standards and regularly tested to cover all external doors and accessible
windows; unoccupied areas should be alarmed at all times; cover should also be
provided for other areas, e.g. server room or Health Laboratories;
iv.
Securing ICT offices, rooms, Health Laboratories and facilities
v.
Physical security for offices, rooms, Health Laboratories and ICT facilities must
be designed and applied.
vi.
ICT buildings housing computing systems such as server rooms, data centres,
Health Laboratories shall be unobtrusive and give minimum indication of their
purpose, with no obvious signs, outside or inside the building identifying the
presence of information processing activities;
Physical entry controls

vii.
Secure areas shall be protected by appropriate entry controls to ensure

that only authorized personnel are allowed access. Access rights to secure
areas must be reviewed and updated every 6 months, and revoked when
necessary.
viii.
Visitors who are at the Organisation for multiple days must follow all procedures
associated with this Guideline on each day of their visit. Longer term contractors
can be sponsored for a photo-ID badge.
ix.
All requests by groups for tours of ICT facility will be referred to the ICT
Department and/or the Human Resources/Administration Department for
handling as an exception.
Protection against external and environmental threats

x.
Physical protection against damage from fire, flood, earthquake, explosion, civil
unrest, and other forms of natural or man-made disaster shall be designed and
applied commensurate with the identified risks.
Working in secure areas

xi.
Physical protection and guidelines for working in secure areas shall be designed
and applied
Public access, delivery and loading areas
xii.
Access points such as delivery and equipment loading/offloading areas and

other points where unauthorized persons may enter the premises shall be
controlled and, if possible, isolated from information processing facilities to avoid
Equipment siting and protection

xiii.
Equipment should be sited or protected to reduce the risks from environmental

threats and hazards, and opportunities for unauthorized access.
Supporting utilities
xiv.
Equipment must be protected from power failures and other disruptions caused
by failures in supporting utilities. In case of such failure, a minimum level of
functioning must be guaranteed
Cabling security
xv.
Power and telecommunications cabling carrying data or supporting information

services must be protected from interception or damage. Controls must be
carried out by entitled persons
Equipment maintenance
xvi.
Equipment must be correctly maintained to ensure its continued availability and
integrity
Security of equipment off premises
xvii.
Security must be applied to offsite equipment taking into account the risks of
working outside Organisation premises.
xviii.
All employees using Organisation issued laptops must ensure that the laptops
are securely locked using physical Kensington locks when unattended.
Secure disposal or re-use of equipment

xix.
All items containing storage media must be checked to ensure that any sensitive
data and licensed software has been removed or securely overwritten prior to
disposal
Removal of property or equipment

xx.
Equipment, information or software must not be taken off-site without prior

authorisation from the ICT Department or his designate.
Photographs and Cameras

xxi.
Visitors are not permitted to take photographs inside of Organisation ICT

premises, server rooms and Health Laboratories sites unless discussed
specifically with sponsoring employees.
For instance, photographs are
sometimes required for documentation purposes. If employees have any
questions about the suitability of photographs, they should consult the ICT
Department.
21.5 Responsibility
Enforcement of this Guideline falls to these offices as indicated in this document.
Administration of the Check-In / Check-Out procedure is the responsibility of identified
individuals in each facility. In most facilities it is a duty of the main Reception Desk.
Roles
All users
Responsibility
Enforcement of this Guideline falls to the organisation as
indicated in this document. Administration of the Check-In /
Check-Out procedure is the responsibility of identified
individuals in each facility. In most facilities it is a duty of the
main Reception Desk.
21.6 Detailed physical security guidelines

Server Room Access controls
i.
The date and time of entry and departure of visitors shall be recorded, and all
visitors shall be supervised unless their access has been previously approved;
they shall only be granted access for specific, authorized purposes and shall be
issued with instructions on the security requirements of the server room and on
emergency procedures.
ii.
Access to server room shall be controlled and restricted to authorized persons

only; authentication controls, e.g. swipe cards plus PIN, keypad controls or other
electronic access control systems must be used to authorize and validate all
access to the server room; an audit trail of all access shall be securely
maintained. Where locks with keys are used, procedures for secure
management of the keys must be put in place.
iii.
Keypad access codes used for physical access to server rooms and equipment
rooms must be unique and changed on a quarterly basis.
iv.
Log books of access to server rooms and equipment rooms and records from
access control systems must be kept secure and archived for six months.
v.
All employees, contractors and third party users and all visitors must be required
to wear some form of visible identification and should immediately notify security
personnel if they encounter unescorted visitors and anyone not wearing visible
identification within the server room or ICT premises;
vi.
Third party support service personnel (such as cleaners) shall be granted

restricted access to server room only when required; this access must be
authorized and monitored whilst accessing the server room;
vii.
Access to the server room must be restricted on a need-to-use basis. Any other
person entering the room must sign the Server Room Access Log giving details
like name, time in, time out, reason for entry, accompanied by, date, etc. This
Guideline includes ICT staff, visitors and contractors like the maintenance team
from suppliers.
viii.
When contractors of Health Laboratories Systems/equipment or Health

Information Systems are on site, testing the network or installing new equipment,
they must not be left unattended in the server room.
ix.
Staff, agents and contractors with access to Organisation premises must be

instructed to ensure that doors with access control should be kept firmly closed
at all times when not in use, not propped or held open in any way and that
separate allowance will be made for safe exits of staff in case of emergency. The
server room must be equipped with doors that automatically close immediately
after they have been opened.
x.
There shall be no clear directions to the server room for outsiders to follow.
xi.
Server rooms or equipment rooms containing systems classified as CRITICAL

must be provided with a CCTV recording camera outside and inside the door(s)
and on other principal perimeter positions to monitor and record access. The
CCTV recording should be backed up in line with the back-up guidelines.
xii.
All equipment and consumables that are taken in or out of server room and
computing facilities must be inspected by local physical guarding staff or agents
and must be signed off in the inventory by the ICT Department or a delegate.
xiii.
Keypad access codes used for physical access to server rooms and equipment
rooms must be unique and changed on a quarterly basis.
xiv.
Access passes, cards, keys or other tokens for entry into server room or
equipment rooms must be retrieved from staff, agents or third-parties when their
employment or contract ceases. Key codes must be similarly changed if known
to departing personnel unless the facility and its access points are guarded 24
hour a day.
xv.
Staff, agents or third-parties working outside normal business hours in server

room or equipment rooms must physically sign an entry logbook maintained by
site guarding staff and display their credentials for access, such as access pass,
written approval, etc.
xvi.
Line managers must inform server room or equipment room (e.g. LIS/HIS)
managers when an employee no longer has a business need to access a facility.
xvii.
Visitors requiring access to server rooms controlled by swipe card access locks
should arrange temporary cards with their sponsor. These cards are limited to
activation windows of 24 hours.
Server room set up controls

xviii.
The server room must not be used as an office for day to day work
xix.
Power supply to the server room must provide for three lines of defence for
backup power: multiple feeds from the public utility; UPS service to provide a
minimum of 20 minutes of backup power; and, diesel generators to sustain
power for longer-term outages. The UPS and, backup diesel-powered
generators are crucial to maintaining a constant flow of power in the event of
a power failure from the public utility.
xx.
The UPS should be sized to energize all computer equipment, HVAC systems
and other electrical devices (such as emergency lighting and security devices)
for 100 per cent of the power demand for no less than 15 to 20 minutes after a
power interruption.
xxi.
Backup generators and UPS provided for Server room and equipment rooms
must be tested regularly in accordance with the manufacturers instructions and
not less than once a month
xxii.
Provide a signal reference grid (SRG) to reduce high-frequency impedance.
xxiii.
Provide maintenance and emergency shutdown switches at all entry points in the
facility. Staff working in Server room and equipment rooms regularly must be
instructed in how and when to use this switch
xxiv.
Heating, ventilation and air conditioning (HVAC) systems must be in place to

maintain humidity and ventilation control systems for the server within the
manufacturers specification.
xxv.
Always ensure an ambient temperature between 70 and 74 degrees F; maintain

a relative humidity of 45 per cent to 50 per cent, and strive for redundant
systems by installing multiple HVAC units.

xxvi.
Automatic Fire protection and suppression systems shall be installed and

suitably placed including detection and abatement systems that most likely will
combine pre-action wet systems interconnected with dry systems (such as FM
200 and Inergen) for sensitive areas, such as disk storage areas.
xxvii.
The server room must have CCTV cameras installed with minimal blind spots to
monitor the server room at all times
xxviii.
Computer equipment must be kept free of dust, smoke, etc. Consideration

should be given to any security threats presented by neighbouring premises, e.g.
a fire in a neighbouring building, water leaking from the roof or in floors below
ground level or an explosion in the street.
xxix.
Food, beverage and tobacco products are prohibited by Guideline around

computer equipment. You must not drink, or smoke in the server room. A NO
SMOKING SIGN shall be hung on the server room door visible to all.
xxx.
The server room floor must have raised floor systems 12 inches for less than
1,000 square feet; 12 to 18 inches for 1,000 to 5,000 square feet; 18 to 24
inches for 5,000 to 10,000 square feet; and 24 inches for more than 10,000
square feet.
xxxi.
The server room shall be fitted with moisture detectors and water proof covers of
the appropriate class or category.
xxxii.
Server rooms and equipment rooms must be fitted with suitably located smoke
and heat detectors at regular spacing to warn of developing fire hazards.
xxxiii.
Hand-held fire extinguishers must be located outside all server room and
equipment room doors and at suitable regular points throughout the facility.
xxxiv.
Local fire and emergency service agencies must be made aware of the location
of all server room and equipment rooms through prior agreements that include
provision for suitable electrical fire fighting equipment, remote alarming,
response procedures, staff registers and false alarm notification procedures
xxxv.
Staff or agents who regularly undertake work in Server room and equipment
rooms must be trained in the use of personal safety and evacuation procedures,
including the use of the fire extinguishers provided and those appropriate for use
on electrical equipment
xxxvi.
Emergency alerting facilities within Server room and equipment rooms must
include provision of a telephone allowing direct external access that would be
functional in the event that main telephone switches become unusable
xxxvii.
All fire detection, alarming, protection and suppression facilities used to protect
Server room and computing equipment rooms, including detectors, alarms,
dampers, sprinklers, gas suppressors, portable extinguishers and fire barriers,
must be tested on a quarterly basis
xxxviii. Server room and equipment rooms must be kept organised and tidy at all times
to comply with fire and safety regulations and insurance requirements
xxxix.
Selectively position perforated tiles in the raised floor to direct chilled air into the
rack area.
xl.
Flood control valves shall be fitted on the raised floor in case of flooding.
xli.
The server room shall be fitted with a fore proof door and wall panels designed
to with stand fire for at least 2 hours.
xlii.
Backup media must be protected from damage due to temperature extremes,

effects of magnetic fields, etc.
xliii.
Severs should have a password protected screen saver on the consoles.
xliv.
Servers shall be locked away in racks or cabinets.
xlv.
Hazardous or combustible materials must be stored at a safe distance from the

server room. Bulk supplies such as stationery, empty equipment boxes must not
be stored within the server room. No flammable, hazardous materials or
chemicals may be brought into Server room and computing equipment rooms
(including paper).
xlvi.
No physical access security mechanism in use in Organisation premises

containing computing facilities or Server room must be designed or implemented
in such a way as to compromise personnel health and safety, especially in the
course of any emergency.
xlvii.
Server room must be fitted with a central and remote alarm routing facility that
will trigger at a suitable fire an emergency service office so that dispatch of
emergency services can be expedited.
xlviii.
Spare IT equipment and computer consumables must not be stored in Server

room or equipment rooms except in separate physically secured enclosures.
xlix.
When equipment is added to a server room or equipment room the capacity of

existing air-conditioning facilities must be reviewed to ensure that it remains
sufficient to purpose.
Network cabling controls

l.
Power and telecommunications lines into information processing facilities shall

be underground, where possible, or subject to adequate alternative protection;
li.
Network cabling shall be protected from unauthorized interception or

damage, for example by using a conduit or by avoiding routes through public
areas;
lii.
Power cables should be segregated from communications cables to prevent

interference;
liii.
Power and telecommunications cables must be installed in armoured conduit

where they leave the building or the Organisation controlled areas
liv.
Power and telecommunications cable inspection and termination points must be

located in locked rooms or locked boxes.
lv.
Data centres must be provided with at least two independently routed trunk
communications links to carrier networks to avoid a single point of failure in
communications
lvi.
Network cabling must be swept for unauthorized attached devices at least once
every 3 months.
lvii.
Clearly identifiable cable and equipment markings should be used to minimise

handling errors, such as accidental patching of wrong network cables;
lviii.
A documented patch list should be used to reduce the possibility of errors;
lix.
Access to network or power cabling, junction boxes, communications equipment

and service ducts in general Organisation premises must be physically restricted
lx.
For sensitive or critical systems further controls to consider include:

a. installation of armoured conduit and locked rooms or boxes at
inspection and termination points;
b. use of alternative routings and/or transmission media providing
appropriate security;
c. use of fibre optic cabling;
d. use of electromagnetic shielding to protect the cables;
e. initiation of technical sweeps and physical inspections for unauthorized
devices being attached to the cables;
f. controlled access to patch panels and cable rooms
21.7 Procedures
ICT Equipment movement procedures
SCOPE: This process applies to ICT equipment that is taken off Organisation premises.
i.
The individual intending to take ICT equipment off Organisation premises fills out
the gate pass with the necessary information and hands it over to his/her
manager/supervisor for approval.
ii.
After the managers approval, the individual intending to move the property
makes two copies of the gate pass.
iii.
At the security office, the individual moving the ICT equipment hands a copy of
filled out gate pass to the security officer who crosschecks the details on the
form against the physical item(s) being transferred.
iv.
If items are being taken out of the warehouse or storage, an approved requisition
form should be attached.
v.
If the details on the gate pass do not correspond with the items being moved, the
individual is asked to return to the security office with a correctly filled and duly
approved gate pass for the items he/she intends to takes out
vi.
If the details on the gate pass correspond with the items being moved, the
security officer endorses all the gate passes, retains the security offices copy
and hands over the other two copies to the individual who ensues to the gate.
vii.
The copy of the gate pass left at the security office is filed for future reference.
viii.
At Organisation premises where there is no resident security officer, the

manager signs the gate pass on behalf of the security function and scans a copy
of it to the security manager.
ix.
At the gate, the gate pass is given to the guard who crosschecks the details on it
with the item(s) being taken out. If all the items being taken out are indicated on
the signed gate pass, the individual is allowed to take the item(s) off
Organisation premises.
x.
If some of the items being moved are not indicated on the signed gate pass, the
individual is asked to fill out a gate pass for the extra items. Only the items
indicated on the duly signed gate pass are allowed off Organisation premises.
xi.
Follow up is made by the security office to ensure that the items were received at
the intended destination. If the items were not received, an inquiry is made into
the matter.
xii.
For items that are being delivered to Organisation premises, on arrival, the gate
pass is handed over to the security officer/guard who crosschecks the details on
the gate pass against the items delivered.
xiii.
If all the items indicated on the gate pass have been delivered, the security
officer endorses all the copies of the gate pass and allows the items to be
brought into Organisation premises.
xiv.
A copy of the gate pass is retained by the resident security officer at the
destination.
xv.
If more items are delivered compared to the number indicated on the gate pass,
the deliverer is asked to obtain a duly signed gate pass for the extra items
xvi.
If fewer items are delivered compared to the number indicated on the gate pass,
the deliverer is asked to present all the missing items. If he or she fails to do so,
the matter is reported to their supervisor so that disciplinary action can be taken.
xvii.
The recipient of the items signs on the delivery note to acknowledge receipt.
Access Procedure for Staff members to ICT premises or LIS/HIS sites

xviii.
When entering Organisation ICT premises, all staff members should clearly
display their identification cards.
xix.
The staff member places his/her luggage including all metallic items in his/her
possession onto the tray/table next to the metal detector and walks through the
detector.
xx.
If the employee doesnt activate the metal detector, his/her luggage is searched
to ensure that harmful items arent being brought in illegally.
xxi.
If the search produces nothing of importance, allow the employee to proceed.
xxii.
If a harmful item is found in the employees possession(s), the employee is

handed over to the security guards for interrogation into the matter.
xxiii.
If the employee activates the metal detector, he/she is asked to put any other
metallic objects on him/her on to the tray/table next to the metal detector and
after the removal of such objects, the employee walks through the metal detector
a second time.
xxiv.
If the metal detector is activated again, request the person to submit

himself/herself to a physical search.
xxv.
A woman may only search a woman.
xxvi.
If the employee is willing to be searched, a guard passes the hand-held metal

detector over the clothes/body of the employee.
xxvii.
If anything suspect is detected, the staff shows the object to the guard.
xxviii.
If the staff refuses to show the suspect object to the guard, he/she should be
escorted off Organisation premises.

xxix.
If it is a harmful object, the employee is detained by the security guard while the
security team is informed.
xxx.
The employee is handed over to the security team or ICT director so that
disciplinary action can be taken.
xxxi.
If the search produces nothing of importance, the employees luggage is

searched to ensure that harmful items arent being brought in illegally.
xxxii.
If the employee refuses to submit to a search, draw his/her attention to the

search procedure and security Guideline and inform him/her that he/she cant
access Organisation ICT premises unless he/she is checked thoroughly.
xxxiii.
If the employee still refuses to be searched, inform the security team so that the
situation can be resolved.
xxxiv.
If the employee has successfully completed the search procedure and is carrying
an Organisation laptop, it is recorded at the reception.
xxxv.
Private laptops for employees are prohibited from entering Organisation ICT
premises; these are left in the custody of the security guard at the reception. In
cases where private laptops enter the organisation premises they shall be
logged with the security and their serial numbers recorded. The usage of the
private laptops for organisational work shall require authorisation from
management in-line with Network access guidelines and user access guidelines.
xxxvi.
After clearance at the reception,

department/desk/workstation.
xxxvii.
When exiting the premises, an employee in possession of an Organisation

laptop is required to register it at the reception.
the
employee
proceeds
to his/her
xxxviii. If an employee is carrying luggage that the guard has deemed suspicious, the
employee is asked to hand over this luggage to a guard who will search it in
order to ensure that no Organisation property is exiting Organisation premises
illegally.
xxxix.
If the employee is clear, he/she is free to leave Organisation premises.
xl.
If Organisation property is found in the employees luggage without proper

authorisation, the employee is handed over to the security team for interrogation
into the matter.
Access Procedure for Visitors (Non-Staff members), contractors (service providers)

accessing ICT department or Organisation sites (LIS/HIS)
xli.
Any visitor/contractor entering Organisation premises should display their

identification card to security (guard).
xlii.
The visitor places his/her luggage including all metallic items in his/her
possession onto the tray/table next to the metal detector and walks through the
detector.
xliii.
If the visitor doesnt activate the metal detector, their luggage is searched to
ensure that harmful items arent being brought in illegally.
xliv.
If the search produces nothing of importance, the visitor proceeds to the

reception desk.
xlv.
If the visitor activates the metal detector, the security guard inquires whether
he/she has any other metallic objects on him/her and after the removal of such
objects, the individual walks through the metal detector a second time.
xlvi.
If the visitor doesnt activate the metal detector the second time, their luggage, is
searched to ensure that harmful items arent being brought in.
xlvii.
If the search produces nothing of importance, the visitor proceeds to the

reception desk.
xlviii.
If a harmful item is found in the visitors possession, he/she is detained while the
security team is informed so that disciplinary action can be taken.
xlix.
If the metal detector is activated a second time, the individual is requested to

submit himself/herself to a physical search.
l.
If the visitor is willing to be searched, a guard passes the hand-held metal

detector over the clothes/body of the visitor.
li.
A woman may only search a woman.
lii.
If anything suspect is detected, the visitor shows this item to the guard.
liii.
If the visitor refuses to do so, he/she should be escorted off Organisation

premises.
liv.
If the visitor refuses to submit to a search, inform him/her that he/she will not be
allowed to proceed unless he/she submits to the search.
lv.
If the visitor remains resistant to the search, he/she should be escorted off
Organisation ICT premises or site.
lvi.
If the visitor has successfully completed the search procedure and is carrying a
laptop, it is recorded at the reception.
lvii.
At the reception desk, the visitor identifies him/herself and notifies the
receptionist of where he/she intends to go and whom he/she intends to visit.
lviii.
The receptionist calls the host in ICT department to confirm if he/she is expecting
the visitor.
lix.
If the host in ICT agrees to receive the visitor, the visitor is given a visitors card
and their identification card is retained at the reception.
lx.
If the visitor is in possession a gun, he/she leaves it in the custody of the

receptionist or the security guard after registering it.
lxi.
The visitor registers in the visitors book.
lxii.
A guard is assigned to escort the visitor to his/her host within ICT.
lxiii.
When the visitor intends to leave Organisation premises, he/she hands over the
visitors card to the receptionist and signs in the visitors book; his/her
identification card is given back to him/her.
lxiv.
If the employee had earlier checked-in a Laptop, computer and related

Equipment, the security guard verifies the serial number the Laptop, Computer
and Related Equipment against what was recorded during Check in.
lxv.
The visitors luggage is searched to ensure that Organisation property isnt being
taken off Organisation premises without the proper authorisation.
lxvi.
If no Organisation property or ICT equipment is found, the visitor signs out in the
registration book, returns visitors card and obtains his/her ID.

lxvii.
The visitor is free to exit the premises
lxviii.
If Organisation property is found in the visitors luggage, he/she is stopped from

leaving the Organisation premises while his/her acquisition of this property is
ascertained.
lxix.
If it is established that the Organisation property or ICT equipment was illegally

obtained by visitor, he/she is handed over to the security team so that
disciplinary action can be taken.
Server room access procedure

lxx.
The employee or visitors sponsor submits signed request for access to server
room by completing a server room access control form stating the reason,
duration and proposed timing of the visit.
lxxi.
Server room access control form is approved by the ICT Department
lxxii.
ICT Department assigns the system administrator or designate employee who is

the custodian of the server room to grant access to the server room
lxxiii.
The system administrator or authorised staff with access rights to the server
room escorts the staff or visitor to the server room
lxxiv.
Both the system administrator, escort and the visitor/escorted persons sign the
data server room access log book indicating time, date and reason for entry.
lxxv.
The system administrator or designate must be present at all times when the
visitor is in the server room
lxxvi.
Once the purpose for the visit has been accomplished, the staff/visitor will sign
out of the visitors log book.
lxxvii.
Exit the server room
21.8 Flow chart
Figure 4: Physical Security and Environmental Controls flowchart
22 Organisation/ICT/02/01/22 - Change Management

22.1 Description
This Guideline ensures standardised methods, processes and procedures are used for all
changes, and maintain the proper balance between the need for change and the potential
detrimental impact of changes.
Change Management is responsible for controlling change to all systems & applications within
the live environment. This includes ensuring that there is a business reason behind each
change, identifying the specific IT services affected by the change, planning the change, testing
the change, and having a back out plan should the change result in an unexpected state. Any
changes that are made to hardware, software, firmware, documentation, etc., throughout the
system lifecycle must be controlled, and must be thoroughly documented.
Effective change management is vital to providing high quality ICT services in the Organisation
computing environment.
22.2 Purpose
To implement formal change management control procedure that protects Organisation
information assets and to ensure that the change management procedure is used for efficient,
planned, authorised and prompt handling of all changes, in order to minimise the impact of any
related incidents upon service.
22.3 Scope
This Guideline addresses the definition and documentation of Organisation information assets
change management control procedures.
This Guideline applies to normal and emergency changes that affect Organisations information
technology systems, hardware, software, systems infrastructure including network, and
databases, and all documentation and procedures associated with the running, support and
maintenance of live systems.
For the purposes of this Guideline, the term changes to Organisations information systems will
include but is not limited to the following categories of changes:
i.
Changes to hardware and hardware configurations;
ii.
Changes to operating systems and operating system configurations;
iii.
Changes to application software programs and application software configurations;
iv.
Changes to data and database configurations;
v.
Changes to user access configurations;
vi.
Changes to network and communication device configurations;
vii.
Changes to configuration of physical access and environmental control devices.
viii.
Problem fixes
ix.
Functionality enhancements

Changes to all information processing facilities, systems, software, or procedure should be
strictly controlled according to formal change management procedures. This section contains
the Standard Guidelines. Each of the statements are arranged in sub sections.
Change Initiation: All system changes will be initiated by filling in the change control form, which
will be signed by the respective heads of department, and addressed to the ICT department.
Change Authorisation: Authorisation for any changes, whether urgent or not, can only be given
by the Head of the ICT Department or Head of the user department if the Head of the ICT
Department is satisfied that the reason for the change is sound and that there is no adverse
effect as a result of the change.
Testing of changes: All testing will be done from a test environment. No change will be applied
to the live/production environment without having been tested in the test environment.
Change approval: The concerned user departments shall check the system to see whether the
results produced are as expected and a user acceptance testing (UAT) form shall be signed off.
A print out of the test results and UAT forms should be attached to the change control form for
final approval before implementation in the production environment.
Change Scheduling: To minimize disruption to the normal working operations of the
organisation, no changes will be effected in the system during normal working hours unless
absolutely necessary. All changes will be scheduled during weekends, public holidays or after
business working hours.
Change Communication: All planned system changes should be communicated in advance to
the concerned parties to minimize on business disruption and inconveniences. For avoidance of
doubt, no scheduled system change should be effected in the live database during a busy
business cycle.
Change Recovery, Safety measures (Back-out plans): Before effecting any change in the
production environment, a backup on a clearly labelled tape drive will be taken and kept for
good. In the event that the change made produces unexpected results, the backup taken before
the change was effected has to be used to restore the database or system to the point before
the change.
Change Support: In the event that the system change requested is beyond the comprehension
of the ICT team, the request will be forwarded to the system vendor. But the due process will be
followed before its implementation in the production environment.
Change Documentation and tracking: All system changes, whether approved or not will be
documented and filed. The documentation will include a duly completed and signed off change
request form, the test results and any other comments/documents used.
Waivers and Exceptions (Emergency Changes): In the event of unexpected critical event that
has adverse effect to the normal operations of the system, the Director of ICT must be
contacted to give a conditional approval. The change control form must still be completed and
submitted to the due process, before commencement.
Separation of Development and operational facilities: The Development, Test and Operational
facilities / environments shall be physically and/or logically separated
Transfer of software between the development test and operational environments shall be
subject to authorization and approval by the ICT Department as per the specific procedures to
be developed and implemented for this purpose.
22.5 Responsibility
Role
Change Requester
Description
This is the staff member or
department requesting the
change /modification of a system
or environment, The Requestor
submits the request for change
Change authoriser This individual should confer with
other individuals as necessary to
come to a conclusion on the
appropriateness of the change
Change Control
The staff member responsible for
officer/Implementer administering change control in
the ICT department.
Change Approver
The staff responsible for
analysing the change and
approving or rejecting the
request.
Responsibility
This person will be the user or
business process lead
Business/Systems Owner
This person will be the ICT

Department
This person will be the Change
Approval Board or ICT Department
22.6 Procedures
This section describes the procedures by which all changes to facility equipment or controls are
proposed, approved and implemented. It encompasses the initiation of a proposed change, the
process by which the proposed change gains management approval, and the procedure by
which the approved changes are controlled during the subsequent design, implementation and
commissioning phases. It also outlines what constitutes a change requiring the use of this
procedure.
Create the Request for Change: The change request will be created by the change Initiator
using a request for change (RFC). Some information shall be recorded directly on the RFC
form and details recorded in other documents and referenced from the RFC, such as impact
assessment reports. The RFC form shall be kept simple in order to encourage compliance with
the process. The changes shall be classified as one of the following;
i.
Normal change
ii.
Significant (high-risk) change
iii.
Standard (pre-approved) change
iv.
Emergency change
With the assistance of the Change manager and subject matter experts, all the
procedures for preparation, installation, verification, and back-out shall be
documented in detail. Impact and risk analysis of the change shall also be recorded, in particular
the worst-case impact, analysing the situation of a failed change and a failed back-out
procedure.
Review, Assess and Evaluate the RFC: A Change Approval Board (CAB) shall be constituted by
the Change Manager and it (the CAB) shall consider each request and filter out any that seem to
be Totally impractical, Repeats of earlier RFCs, Incomplete submissions, such as those with
an inadequate description, or without necessary budgetary approval or justification, These
shall be returned to the
initiator, together with brief details of the reason for the rejection, and the log shall record this
fact.
During this phase, there shall be a check of the following aspects of the proposed change Correctness of all technical information, including preparation, implementation,
verification, and back-out procedures, Completeness of change, testing procedures, and
documentation, Feasibility of the change, Potential side
effects and impact on other services or infrastructure, Worst-case impact (both change and backout procedure fail) This review shall be facilitated by technical subject matter experts coopted by the CAB familiar with the area affected by the change.
The potential impact to services and service assets and configurations shall be fully considered
during this phase. When conducting the impact and resource assessment
for RFCs referred to them, the CAB shall consider relevant items, including;
v.
The effect of not implementing the change,
vi.
The resources required to implement the change,
vii.
The current change schedule and projected service outage (PSO),
viii.
Additional on-going resources required if the change is implemented, the impact of

the change on operations, the infrastructure and customer service, other services
that run on the same infrastructure, Continuity plan, capacity plan, security plan,
regression test scripts, and data and test environment
The CAB shall evaluate the change based on

ix.
Impact
x.
Urgency
xi.
Risk
xii.
Benefits
xiii.
Costs
The CAB will use the following simple matrix to categorize risk.
Impact
High Impact
Low Probability
Low Impact
Low Probability
High Impact
High Probability
Low Impact
High Probability
(Candidate for standard change)
Figure 5: Change Approval Board Risk Matrix
Probability
The priorities of proposed changes shall be established based on the assessment of the impact
and urgency of the change. Initial impact and urgency will be suggested by the change initiator
but may be modified in the change authorization process.
Impact shall be based on the beneficial change to the business that will follow from a successful
implementation of the change, and on the degree of damage and cost to the business due to
the error that the change will correct. The configuration Manager will be responsible for
performing a baseline assessment of the IT environment. The CAB will use this baseline
assessment in evaluating the impacts of a change.
The urgency of the change shall be based on how long the implementation can afford to be
delayed. Below are the IT Change Priority descriptions
Priority
Immediate
Treat as emergency change
High
To be given highest priority for
change building, testing,
and implementation resources
Corrective Change
Putting operations at risk. Causing significant loss of
revenue or the ability to deliver important services.
Immediate action required.
Severely affecting some key users, or impacting on a
large number of users.
Medium
No severe impact, but rectification cannot be deferred

until the next scheduled release or upgrade.
Low
A change is justified and necessary, but

can wait until the next scheduled release
or upgrade.
Authorize the Change

Formal authorization shall be obtained for each change from a change authority. The
levels of authorization for a particular type of change shall be judged by the type,
size, or risk of the change, the following shall act as change authorities for the
different classifications of the changes
Scope/Type of Change
Standard change
Emergency change
Normal change
Significant (high-risk) change
Change Organisation
XXXXXX
Emergency CAB
CAB
ICT Department
Plan the Updates

Many changes shall be grouped into one release and may be designed, tested, and
released together if the amount of changes involved can be handled by the business
and there is little risk of interference between the changes. The CAB shall schedule
changes to meet the needs of the business rather than for the convenience of IT. This
planning of the changes shall be conducted by the change manager together with the
operations Division resource in charge of Release Management.
Implement the Change
Authorized RFCs shall be passed to the relevant resources in the relevant section for
building of the changes. The Change Manager shall have the responsibility for
ensuring that changes are implemented as scheduled. The following tasks shall be
performed during this phase:
xiv.
Build the change
xv.
Pre-test the change
xvi.
Complete change deployment plan
xvii.
Implement the change
Testing of the Implemented Change

A post-implementation review (PIR) shall be carried out by a resource nominated by the
CAB and supervised by the Change Manager to confirm that the change has met its
objectives, that the initiator and stakeholders are happy with the results, and that there
have been no unexpected side effects. Lessons learned shall be factored into future
changes.
Close the Change
The change manager shall close the change by signing off at the RFC (Request For Change)
Form section application of closing changes and the sign off will be documented in the
configuration database by the CMDB Manager. It is important to note that every step of the
change process and every status change of the RFC must be documented in the configuration
database. The change success, failure, related plans shall be communicated to all
stakeholders (Initiator of the change, ICT Department, heads of Business units affected and
head of the operation division) by the Change manager on behalf of the CAB.
22.7 Emergency Change procedures

An emergency change is one that is required to be applied immediately to ensure the
application or system continues functioning and cannot wait for a scheduled change. They still
require approval by the system owner or the system owners deputy if the owner is not
available.
Emergency changes are not a panacea for lack of planning by the ICT Department and care
should be taken to ensure they are not abused.
The following procedures apply to emergency changes.
i.
A critical application error is reported to ICT. This error is documented and recorded
through ICT Help desk.
ii.
ICT Help desk will assign the problem to a Senior Owner Department staff member
for immediate action.
iii.
The developer creates a fix or work around for short term resolution of the problem.
iv.
The short term fix will be submitted to operations for immediate implementation in
the Test environment.
v.
Operations will immediately migrate it to Test and inform the software development
that it has been migrated.
vi.
The developer will immediately test the fix to ensure that it works as desired.
vii.
Upon successful testing, the developer will report to ICT Department that the
change is ready to implement, and will obtain verbal approval to proceed.
viii.
The developer will submit the change to Operations for implementation in

Production.
ix.
Operations will immediately migrate it to Production, and will inform the developer
that it has been migrated.
x.
The developer will immediately test the change in Production to validate that the
problem has been corrected.
xi.
If the change does not fix the problem, or it creates a new problem, Operations will
be directed to restore the previous content to production, and the emergency

change process will begin once more.
xii.
If the change fixes the immediate problem, the developer will record the details of
the change made, and will initiate a formal Change Request (RFC) for a more
detailed and thorough review and correction of the problem. This will initiate the
normal change control process.
xiii.
The software developer will report the results to ICT Department.
22.8 Flow chart

Normal change process flow
Figure 6: Normal Change Management Flowchart
Emergency change process flow
Figure 7: Emergency change process flowchart
23 Organisation/ICT/02/01/23 - Security Monitoring

23.1 Description
This Guideline and its supporting standards outline the requirements needed to protect
Organisation through the enforcement of logging, monitoring and auditing processes
This section defines the Organisation security monitoring Guideline.
Other sections in this ICT Guidelines and procedures manual may include monitoring Standard
Guidelines particular to the IT are being detailed in that section. Those Standard Guidelines
take precedence if they are not consistent with a Standard Guidelines in this section.
23.2 Objective
To provide for the tracking of computing resource activity that will benefit the disclosure of
unauthorized activity.
To ensure that the security status of Organisation is known and understood by those who are
responsible for maintaining that security.
To provide a mechanism to retrieve and report information on logged events; and
To allow reporting on the effectiveness and compliance to systems security requirements.
To identify suspected or actual misuse or abuse and enable the enterprise to respond before
serious damage is done.
23.3 Scope
The tracking of security related events and the data logs produced by the tracking mechanisms

All accesses that are denied will be logged. Each denied access is considered a security
"event", but not necessarily a security "violation". Daily logs of all security events will be
reviewed for unusual security events with further investigation of unusual events.
Sufficient information for after-the-fact investigation of unauthorised activity must be logged. At a
minimum the information in the tracking record associated with each event must include: User
ID; Associated terminal, port, network address, communication device; Information or system
accessed; Date and time of access; and Event Description
Organisation computing resources should be sufficiently monitored by IT security manager to
detect deviations from authorized use.
Regular monitoring of the secure status of all Organisation electronic information must be
undertaken, principally through the applications, platforms and infrastructure that supports it.
Monitoring of user activity on Organisation applications and the platforms supporting them must
be undertaken on a regular basis, using the logs of user activity provided by those systems.
Monitoring of secure configuration of Organisation applications and the platforms supporting

them must be undertaken on a regular basis, by comparison with the desired secure
configurations published in Organisation's platform security technical standards.
Monitoring of security events affecting Organisation applications and the platforms supporting
them must be undertaken on a continuous basis, by capturing alarms triggered by particular
platform or infrastructure security mechanisms, and by intercepting specific types of traffic
passing across Organisation networks and network boundaries.
Security event monitoring on Organisation systems and networks must be continuous and be
linked to incident management and response.
Any actual or suspected breach of security or related incident will be reported, recorded and
appropriate action taken to limit and remedy any impact on the security of the Organisation.
Organisation reserves the right to conduct all such monitoring activities on its systems as are
necessary to preserve and measure the security of its information and assets.
All employees, agents and contractors who make any use of Organisation systems must be
informed of the Organisation's right to monitor all such use and inspect any information
entrusted to Organisation systems, whether personal or not.
Monitoring of Organisation systems and access to logs and other information produced during
monitoring must be restricted to employees specifically authorised to conduct such monitoring
as part of their normal duties.
Organisation or its employees or agents must never seek to access information outside the
scope of Organisation owned or operated systems, or outside the public domain, without either
obtaining permission and assistance from the relevant system owners or operators, or from
properly designated legal or law enforcement agencies in the most relevant locale.
Where circumstances dictate the extension of monitoring activity and monitored information to
other properly designated employees or agents of Organisation (e.g. Internal Audit staff), this
must only be done after specific approval by the Organisation IT security manager, the
Organisation ICT Department or their authorised delegates.
Where circumstances dictate the extension of monitoring activity to information not normally
monitored as part of the operational schedule, this must only be done after specific approval by
both the Organisation, Director of ICT or their delegates.
Measures must be put in place to protect logging facilities and log information against tampering
and unauthorized access.
The clocks of all relevant information systems (e.g., networking devices, servers, and PCs)
must be synchronised with an accurate time source for accuracy of timestamps on logs.
23.5 Responsibility
Each System owner is responsible for ensuring he / she fully implements the principles and
procedures as set forth in this Guideline.
Roles
All Users
Responsibilities
All Organisation users (employees, customers,
suppliers, and business partners) who are in
possession of, or control access to
Organisation information or computers
covered by this Guideline are responsible and
accountable for its protection in accordance
with this Guideline and supporting guidelines
and procedures.
23.6 Procedure
Logging procedure
i.
On a daily basis:
The IT security manager will liaise with the business unit manager or system
owner to set up the respective system to log the following security events on a
daily basis:
a. All security violations, such as System access denied, Invalid password,
Invalid security certificate, Password revoked, and Resource access
denied
b. All accesses to sensitive/significant areas of the systems.
c. All security commands issued using the security administrative authority.
d. All accesses to operating system resources, with the exception of the
default access. If the resources can be read publicly, record the update or
allocation and deletion of access
e. Successful connections;
f.
Denied connections and rejected attempts
g. Failed attempts to access files, resources and other object;

h. Successful attempts to access Organisation information;
i.
Logon successes and failures;
j.
Error messages and alerts;
k. Lengthy connection times;

l.
Duplicate user names and concurrent user sign-on;
m. Account creation and maintenance;

n. Remote access by vendors for maintenance or diagnostics;
o. Firewall activity;
p. Internet activity, including but not limited to web sites visited, files
downloaded, time spent on the Internet and related information or
management decisions regarding the type of Internet usage appropriate
for departmental business activities
The identity of the user, or processes activated by the user, must be maintained for the duration
of the session. For example, some programs change mode or privilege during execution. This
should not result in the loss of the audit trail or identity of the user.
The following information must be logged for each securityrelated event that occurs within
each application or infrastructure environment:
ii.
Event type/description (e.g. unauthorized logon);
iii.
Process or user identifier associated with event;
iv.
Workstation/terminal identifier and network address associated with event;
v.
Files or objects affected by event
vi.
Date and time of event;
vii.
Identifier of platform and application recording the event.
The following changes to users access control and rights that may occur within each application
or infrastructure environment must be logged:
viii.
Creation of a user profile;
ix.
Deletion of a user profile;
x.
Renaming of a user profile;
xi.
Modification of user profile access rights;
xii.
Change to user profile password characteristics.
The following must be logged as evidence of unauthorized or unusual use:

xiii.
Successful login and logout;
xiv.
Unsuccessful login;
xv.
Attempt to login outside of defined working hours;
xvi.
Failed attempt to access controlled files, directories or other resources;
xvii.
Unauthorized access controlled files, directories or other resources.
xviii.
Changes of user passwords must be logged.
The following changes to the operation or content of the security audit log that may occur must
be logged:
xix.
Change to auditable events;
xx.
Successful attempt to access audit log;
xxi.
Unsuccessful attempt to access audit log;
xxii.
Direct modification of audit log;
xxiii.
Deletion of audit log or change in log location or refresh characteristics
Logon Monitoring
xxiv.
A user event logging system shall contain at a minimum the following information:
a. User ID
b. Dates and times of logon and logoff.
c. Logon method, location, terminal identity (if possible), Network address

d. Records of successful and unsuccessful system access attempts
e. Records of successful and rejected data access and other resource
access attempts.
Check Log Integrity
xxv.
On bi-annual basis check that:
a. All critical servers connected to Organisations internal network must have
the current time accurately reflected in the internal clock. Automated
methods must be used to accurately synchronize these systems.
b. Computer security relevant event logs must be retained for a period of time
appropriate for the particular environment.
c. To ensure that users are held accountable for their actions on
Organisation systems or network elements, logs and records tracing
relevant events to specific users must be securely maintained.
d. Mechanisms to detect and record significant computer security events
must be resistant to attacks. These attacks include attempts to deactivate,
modify or delete the logging software or the logs themselves.
Log Review
xxvi.
On a monthly basis:
a. Obtain event logs from all the systems configured to capture events as per
procedure 8.8.2
b. Check for any actual or attempted misuse of, or unauthorized access to,
Organisation computing systems, networks or facilities and report to the IT
Security Officer.
c. Review system integrity reports to detect changes to critical system
components, such as files, directories or services.
d. Security logs on all applications and infrastructure components must be
either inspected in situ on a regular and timely basis or else moved to offline storage for further inspection and archival.
e. Where operational capacity and performance constraints require that
security logs on applications and infrastructure components be overwritten
once a size limited has been reached, the logs must be moved to off-line
storage or inspected in full in situ before the overwriting is triggered.
f.
Offline archived application or infrastructure security logs must be
retained for a defined period of time; this time period must be consistent
with relevant local legal and regulatory requirements, and business and
operational requirements.
24 Organisation/ICT/02/01/24 - General Software Guideline

24.1 Description
Software refers to programs that are installed on computers to perform specific tasks. Software
programs purchased and provided by (Organisation) are to be used for creating, researching,
and processing Organisation-related processes.
This software Guideline shall be read in conjunction with the detailed Guideline in Annex I
Annex II, Annex III, Annex IV
24.2 Objective
To Ensure Management, permanent and temporary employees and contractors of Organisation
are aware of the appropriate use of software, the inherent risk of using pirated software and
caution them against practices that can result to infringement of software license and copyright.
24.3 Scope
This Guideline applies to all software including server and client operating system software,
application software, custom developed software and utility software, not only to any original
installation but also to any upgrades to later versions of the software, which must also be
properly licensed

Organisation may develop and distribute proprietary (Organisation created) software. This may
be loaded on an employees computer at the discretion of ICT department and should only be
used whilst employed at Organisation.
Employees needing software other than those provided by the organization as standard
installations must request such software from the ICT department. Each request will be
considered on a case-by-case basis in conjunction with the ICT Department.
Users must comply with copyright and licensing restrictions and with applicable Organisation
Guidelines. ICT resources may not be used to violate copyright or the terms of any license
agreement. Unauthorized downloading and distributing of copyrighted material is prohibited. No
one may use Company ICT resources to inspect, modify, distribute, or copy proprietary data,
directories, programs, files, disks or other software without proper authorization.
All software acquired for or on behalf of the organization or developed by organization
employees or contract personnel on behalf of the organization is and shall be deemed
organization property. All such software must be used in compliance with applicable licenses,
contracts, and agreements.
All purchasing of Organisation software shall be centralized with the Finance and Administration
Department in consultation with the ICT Department to ensure that all applications conform to
corporate software standards. All requests for corporate software must be submitted to the
Departmental head for approval. The request must then be sent to the ICT, who will then
determine the software that best accommodates the desired request.
The ICT department is exclusively responsible for installing and supporting all software on the
Organisations computers.
Most of the software titles on organizations current software list are not freeware; therefore, the
cost of software is a consideration for most titles and their deployment. It is the goal of the ICT
department to keep licensing accurate and up to date. The ICT department is responsible for
purchasing software licenses in liaison with the Finance and Administration Department
All software used for or on behalf of Organisation shall be correctly and appropriately licensed
and used only in conformity with the terms of the license, whether the usage is on hardware
belonging to Organisation or not.
No staff member, contractor or agent working for or on behalf of Organisation shall copy and/or
install software onto any Organisation computers without prior electronic or written approval
/confirmation from the person(s) nominated by ICT Department.
It is the responsibility of the ICT department to ensure that Organisation has the
necessary software licenses for all software installed or authorised to be installed on
Organisations computers or computers used by Agents or Contractors conducting business on
behalf of Organisation.
All copies of any illegal software installed by employees on Organisation computers shall be
uninstalled immediately. This includes legally purchased software that has not approved in
writing or in electronic format by the Organisation ICT management.
Where development of applications or infrastructure is being conducted by third-parties, specific

measures must be taken to ensure that the security of both the development process and the
delivered code are protected, as well as the fulfilment of security requirements derived from
Guideline.
Where development of applications or infrastructure is being conducted by third-parties, the
contract must specify that Organisation Information Security Guideline will be applied to the
governance of development and to derive the security requirements for the development.
Where development of applications or infrastructure is being conducted by third-parties within
Organisation owned and controlled development environment, all the requirements of Guideline
must be applied to the activities of the third party and a suitable contractually binding agreement
must govern the security of the arrangement.
Where development of applications or infrastructure is being conducted by third-parties in a
third-party development environment, this environment must not be connected directly to any
Organisation network and the contract must provide suitable assurances that the developed
code must have been kept secure during development.
Where development of applications or infrastructure is being conducted by third-parties in a
third-party development environment, specific reviews of delivered code must be undertaken
once it is delivered to Organisation to provide assurance that the security of functionality has not
been compromised by another party during development.
Open Source Software (OSS) is software whose source code is openly published, is often
developed by voluntary efforts and is usually available at no charge under a license defined by
the Open Source Initiative which prevents it from being redistributed under a more
restrictive license. OSS is also subject to the requirements and restrictions stipulated in this
software Guideline and govern its acquisition and use within Organisation
All purchased, pre-developed and packaged software acquired for use within Organisation must
be subject to the same security controls as bespoke software.
All packaged software acquisitions must be subject to a formal risk analysis to determine the
necessary security requirements derived from Guideline.
Security requirements must have been produced, at least in draft form, and used as part of the
selection process before packaged software is acquired for use in Organisation.
Where all purchased software functionality does not fulfil the security requirements derived from
Guideline for a specific application or infrastructure and the vendor is unable to modify to
comply then the standard process for the granting of a Risk Acceptance by the business owner
or a Guideline Dispensation must be adhered to.
Contracts for the purchase of pre-developed packaged software or for the development of
software by third parties must provide clarity and protection of Organisation rights over
licensing, ownership of code, escrow access to source code and intellectual property.
All packaged application software must be screened for viruses prior to distribution and
installation; all such software must be operated in an environment that is protected by a full
implementation of Organisations standard Anti-Virus controls.
All third-party software used in business applications (or as part of an associated business
process) must be from reputable sources whose reliability, legal status and past performance
has been verified. The use of unsupported or non-marketed software, such as freeware or
shareware, must not be made without a source code review.
All third-party software used in business applications (or as part of an associated business
process) must be properly designed for the use to which it is applied and must be properly
licensed for its use within Organisation from the originator, vendor or their agent(s). All
associated intellectual property or copyright must be respected at all times during its use or
exploitation within Organisation.
All proposed software into the Organisation ICT environment should have a supported business
case and such a business case should be approved by the user department head and the ICT
Department
No pirated software, i.e. computer software which one possesses illegally, is permitted to be
used either on Organisation's computer or on Personal computers for Organisations business.
When implementing Commercial off the shelf solutions, similar considerations should be part of
the evaluation. The functional requirements of a system should:
i.
Document the process of the process flow for the automated process
ii.
Should specify the competencies and roles that are required to complete the
process.
iii.
Specify the key performance indicators required for the process to be completed
iv.
Specify the key inputs and expect outputs for each process
Only trained and experienced programmers shall be allowed to develop or customise internally
developed software.
Regarding outsourced software Organisation shall ensure that competent and approved
development and customisation team shall work on the project.
Prior to the implementation of new or upgraded information systems, care should be taken to
ensure that all requirements for acceptance have been met.
24.5 Responsibility
Roles
Software developers (Vendors)
Organisation system users

Organisation ICT department
Responsibilities
Shall be responsible for building of
supplying the software in accordance
with the general software guidelines and
related software development guidelines
Shall comply with the guideline and
ensure that they only used approved
software on their computers
Management of software in accordance
with the software guidelines
24.6 Procedure
The following is the procedure that shall apply in the acquisition of software
User department will present a business case for the new software
Conduct a feasibility study or business case validation for the request for new software.
Business case is approved by Director of ICT and User Department or shall be rejected and
sent back to the user department for additional information.
Once business case is approved Software development section shall validate the requirements
and assess whether Organisation has the capacity to develop the software in-house.
If Organisation does not have the capacity to develop the software, the software will be
acquired through tendering from external vendors who will be responsible for providing an off
the shelf package.
Detailed requirements for the software will be developed and such requirements will include
functional, technical and security.
The requirements will be approved by the Software development section head, ICT Department
and the head of the user department.
For both in-house development and external or outsourced development/customisation design
for the system shall be documented outlining the software architecture and functionality.
Once the solution design is completed the design shall be approved by the ICT Department,
Software development section head and the vendor head if the software is outsourced.
The software shall be developed by either the Organisation internal team or the vendor based
on the solution design.
Once completed the software shall be tested by the user department and approved by the user
department head and head of software section and ICT Department.
If the software does not meet user requirement is shall be reverted back to development for
further customisation or developed
The software shall be licensed and handed over to the user for usage.
24.7 Flow Chart
Figure 8: General Software guideline flowchart
25 Organisation/ICT/02/01/25 - ICT Quality Management

25.1 Description
Quality Management is a process of identifying quality aspects regarding acquisition and
implementation of new ICT software, hardware and network equipment and ICT projects it is a
process for confirming whether Organisation is maintaining high quality standards.
25.2 Objective
To ensure that quality standards are implemented when acquiring computer hardware and
software for usage within the Organisation environment.
This Guideline would ensure that quality standards are observed by all Organisation ICT
department personnel when they acquire and introduce new hardware, software and network
equipment into the Organisation operating environment
25.3 Scope
This Guideline applies to the acquisition of new hardware, networking and software within
Organisation ICT environment
This applies to all software, network and hardware and ICT related projects.

All software, hardware and network equipment that shall be acquired and installed in the
Organisation environment shall be compliant with the user requirements.
All off the shell software, hardware equipment and network equipment shall be acquired from
reputable ICT companies with verifiable references and the same Organisation must comply
with procurement regulations of Organisation.
The acquisition process of all ICT related project, services, equipment must be compliant with
quality standards for Organisation.
Quality should be observed at implementation of ICT project as well as installation of computer
hardware and network equipment.
The implementation and installation of Software, hardware and Networks shall be compliant with
the hardware Guideline, software Guideline and ICT project management Guideline
All off the shelf software identified for acquisition should satisfy user requirements and should
ensure minimal customisation where possible.
Vendors for off the shelf software, hardware and network services should have implemented
demonstrated experience in performing similar or related projects.
The vendor should be able to offer support for the software post the implementation of the
software.
All software applications should have a licensing agreement that is consistent with the Software
Guideline
A knowledge transfer plan should be developed and approved in the acquisition process to
ensure that internal staff develops the capacity the support the software, hardware and network
services
An implementation methodology should be developed and approved in acquisition of the
software.
Installation and implementation of new hardware, network and software should be compliant
with the project management standards and approach as specified in the hardware and
software Guideline
The Quality Assurance shall ensure that the implementation of the ICT project is in line with the
various Guidelines related to software, hardware and Network within Organisation and where
there are variations flag all the issues to the ICT Department and the project manager
responsible
25.5 Responsibility
Roles
ICT Department
Quality Assurance
Responsibilities
Apply ICT Quality Standard in all
operations
Test for Quality in ICT Operations
25.6 Procedure
This procedure shall apply to the quality processes in ICT projects
At acquisition software, hardware and network devices perform quality control check as follows;
Inspect whether the process of acquisition of software is compliant with the software Guideline
Inspect whether the processes of Hardware and Network equipment acquisition is compliant
with the hardware Guideline, software Guideline and network Guideline
Inspect whether the software requirements are compliant with the software Guideline
Inspect whether the hardware requirements is compliant with hardware Guideline quality
standards.
During the implementing ICT projects confirm if the ICT project are being implemented in
accordance with the software Guideline, hardware Guideline, network Guideline and the ICT
project management Guideline.
25.7 Flow Chart
Figure 9: ICT Quality Management Flowchart
26 Organisation/ICT/02/01/26 - Incident Management

26.1 Description
An incident is any event which is not part of the standard operation of a service and which
causes, or may cause, an interruption to or a reduction in, the quality of that service. Forms of
incident shall include any form of ICT related incident affecting the WAN, LAN, Information
Systems, Web Portal.
The stated incident management objective is to restore normal operations as quickly as possible
with the least possible impact on either the business or the user, at a cost-effective price.
Incident management shall be read in conjunction with the detailed incident procedures and
guidelines that are in the appendix section. This will reduce the time spent in recovering from
incidents and will help in minimising the effects of an incident after it has happened and will help
in preventing recurrence.
26.2 Objective
To respond to serious attacks quickly and effectively, reducing any potential business impact
and to reduce the risk of similar incidents occurring.
To ensure that Organisation is able to identify perpetrators of malicious acts and that
Organisation preserves sufficient evidence to prosecute them if required.
26.3 Scope
The purpose of this Incident Management Guideline is to provide a structured method to
managing the incidents that are within Organisation.
The scope of incidents is limited to incidents that require the activation of the Computer Incident
Response Team.
This does not cover operational incidents that are managed by the service desk.
This guideline also does not cover incidents that have been escalated to disaster management

All incidents must be recorded reviewed and resolved using an incident management process.
Incident management communications must be limited to those individuals defined in the
communications plan. Details of incidents should only be shared with individuals on a need to
know basis.
Where it is necessary to make changes to systems, applications or networks the incident
response procedure must feed into any existing change management process.
Incidents must be reviewed to identify common threats and trends.
Access to the information security incident management system must be restricted to authorised
individuals.
Potentially compromised technology must not be used for any element of the information
security incident reporting process.
A process to maintain contacts with relevant authorities to support the information security
incident management process must be documented.
There must be mechanisms in place to enable the number, frequency, types and impact of
information security incidents and issues to be quantified and reviewed.
A clear point of contact must be established for all employees, contractors and third party users
allowing them to raise information security incidents.
A point of contact must be available to respond to information security incidents at all times.
All users (including third party users) of Organisation ICT Services must be made aware of their
responsibility to report suspected or actual information security noncompliance, and incidents,
and the correct process for reporting information security incidents.
The security incident owner must track the information security incident to resolution and
closure.
All users (including third party users) made aware of an information security incident must report
it to the central information security incident response team in Organisation Global Information
Security.
Once incidents are identified measures should be put in place to ensure that the incident does
not spread to other systems or areas within the network.
Only (Computer Incident Response Team) CIRT members with the support of ICT technical
team shall be authorised to contain the incident(s). (The full list and terms of reference in of the
CIRT is found in the annex section)
Due care should be taken by the CIRT to ensure that the incident containment process does not
result in loss of evidence which will be key in resolving the cause of the incident.
Once incidents are identified measured should be put in place to ensure that the incident does
Only CIRT members with the support of ICT technical team shall be authorised to contain the
incident(s).
Computer incidents shall be separate from the Organisation disaster management incidents.
All identified disaster management incident shall be escalated to the disaster management
team.
All traces of ICT incidents must always be removed so as to prevent re-occurrence
The CIRT shall be responsible for coming up with recovery procedures for the incidents
As part of recovery the CIRT shall maintain and refer to previous incident logs for reference in
recovery.
Once recovery is successful the recovery procedure shall be recorded in the lessons learnt and
recovery procedure in the incident log
Only members of the CIRT and competent ICT Technical staff shall be allowed to manage the
recovery process
The CIRT team shall be responsible for evaluating the incident report with the objective of
updating the incident log as well as educating the CIRT team
Once an incident is resolved a formal closure process should be initiated through the CIRT
All information about the incident must be recorded and stored for future reference
26.5 Responsibility
Ref
Department
CIRT
Role(s)
The CIRT is comprised of a Team Leader and team members
with various roles and responsibilities.
The Team Leader is responsible for the following:
1. Making the judgement on whether the incident
should be classed as an Incident type I or II.
2. Constituting the appropriate CIRT for the incident
and assigning technical and support (e.g.
research, scribing and welfare) responsibilities.
3. Providing
a central reporting point and
coordinating response efforts.
4. Scheduling periodic status update meetings as
appropriate.
5. Ensuring that the CIRT follow set procedures in
responding to incidents and that documentation
of events is comprehensive.
6. Escalating the incident information to department
management. Providing a contact point for
support departments.
Technical Team members are responsible for the following:

7. Promptly responding to queries and requests
from the Team Leader.
8. Participating
in evaluating and resolving
incidents.
9. Accurately and comprehensively documenting
their actions.
10. Evaluating the incident response.
The Welfare role (optional) is responsible for the following:

1. Ensuring team members have access
to the premises outside regular
working hours if required.
2. Organising safe parking for team
members outside regular working
hours.
3. Provision of refreshments for team
members required to work long hours.
Transport to and from work, if required.
Note: All members of the ICT Department are potential
Technical and Support Team members.
Users
a. Users should immediately report any suspicious activity
that may indicate a security incident is in progress to the
Help Desk administrator. For example virus warnings,
unusual behaviour of the workstation, unreasonable
figures in applications, denial of service etc.
ICT Department managers
a. IT department managers work with the CIRT leader
to provide the required skills to execute this IRP. In
addition, Managers ensure that their staff know
the
reporting
procedures contained in this
document and are aware of the IT Procedures
manual of the Organisation.
a. System Administrators report any suspicious activity
or actual technical faults on the network
infrastructure (devices, servers etc.) to the CIRT
leader. They may also be called upon by the CIRT
leader to determine and implement a solution.
Security Administrators
a. Security Administrators report any suspicious activity
reported by the monitoring tools to the CIRT leader.
They may also be called upon by the CIRT leader to
determine and implement a solution.
Support Departments
a. Support
departments
include
Administrative
Services, Human Resources, Security, and Legal
who may be required to participate in resolution of
the incident. ITD management will request them for
support in incidents that require their involvement for
example if the incident is caused by a power failure
or is deliberately caused by a staff member or if
there is likely to be violence. Request will be made

according to the communications plan (Appendix A).
b. When support departments participate in incident
resolution, they will be responsible for accurately and
comprehensively documenting their activities and
submitting the report to the CIRT leader. Activities
will be recorded in the Actions Taken Form
(Appendix B).
Vendors
a. Vendors work with the CIRT team to resolve the
incident.
26.6 Procedure
The diagram below shows the processes involved in proper Incident Management
Figure 10: Incident Management Process
Logging
The essential first step in managing incidents correctly is to receive and log them.
Incidents may be reported from various sources, such as users, application
managers, the User Help Desk or technical support, among others.
Incidents should be logged immediately as it is much more difficult to log them later
and there is a risk of new incidents emerging, causing the process to be postponed
indefinitely.
The following are key activities that must be performed in the incident logging process
i.
Commencing handling of the incident: the User Help Desk must be able to evaluate
whether the service required is included in the customer's SLA in the first instance
and if not, forward it to a competent authority.
ii.
Checking that the incident has not already been logged: it is commonplace for more
than one user to report an incident, so it is necessary to check to avoid unnecessary
duplication.
iii.
Assigning a reference: the incident will be assigned a reference number to

uniquely identify it in both internal processes and when communicating with the
customer.
iv.
Initial logging: the basic information needed to process the incident (time,
description of the incident, affected ICT systems ) has to be entered on the
associated database.
v.
Supporting information: Any relevant information for the resolution of the incident
that may be asked for from the client using a specific request which can be
requested from the helpdesk.
vi.
Incident notification: in those cases where the incident may affect other users,
these should be notified so that they are aware of how the incident may impact their
usual workflow.
Classification
The main aim of incident classification is to collect all the information that may be
used to resolve it.

The classification process should implement at least the following steps:
vii.
Categorisation: a category is assigned (this may in turn be subdivided into several

levels) depending on the type of incident and the workgroup responsible for
resolving it. The services affected by the incident are identified.
viii.
Establishing the level of priority: the incident is assigned a level of priority, based
on predefined criteria, depending on its impact and urgency.
ix.
Allocation of resources: if the User Help Desk cannot resolve the incident in the
first instance, it will designate the technical support personnel responsible for
resolving it (second level).
x.
Monitoring the status and the expected response time: an incident is associated
with the incident (for example, logged, active, suspended, resolved, closed) and the
resolution time for the incident is estimated based on the relevant SLA and the
priority.
Diagnosis, Resolution and Closure

If the User Help Desk is unable to resolve the incident it will forward it to a higher
level for the experts assigned to investigate. If these experts are unable to resolve the
incident, the predefined escalation protocols will be followed.
Throughout the lifecycle of the incident, the various agents involved must update the
information stored in the databases so that all the levels involved have complete
information on the incident's status.
If necessary, a Request for Change (RFC) may be raised. If the incident is recurrent
and no definitive solution is found, Problem Management should also be informed so
it can study the underlying causes in detail.
Once the incident is solved the following steps should be taken:
xi.
Confirm with users that the solution is satisfactory.
xii.
The resolution process should be added to the Knowledge Base (KB).
xiii.
The incident should be reclassified if necessary.
xiv.
The information on the Change Management Database (CMDB) about the

configuration items (CI) involved in the incident should be updated.
xv.
The incident should be closed
26.7 Responsibility
Roles
User
Helpdesk
CIRT
Responsibilities
Shall be responsible for logging all incident and passing them on the CIRT
Shall manage the escalation process of the incidents
26.8 Flow Chart
Figure 12:
11: Incident Management Flowchart
27 Organisation/ICT/02/01/27 - Contingency Planning

27.1 Description
An ICT Contingency Plan refers to a plan for recovering ICT services following a system
disruption. Such measures may include the recovery of ICT functions using alternate equipment
or the relocation of ICT systems and operations to an alternate site. The ICT Contingency
provides guidance to ensure that Organisation is able to do the following before, during and
after a disruptive event:
i.
Process and manage critical information,
ii.
Maintain national and international communications,
iii.
Maintain Internet access,
27.2 Objective
ICT contingency planning is be part of the fundamental mission of the Organisation as a
responsible and reliable public institution.
To ensure the continuous performance of the Organisation information systems especially
during emergencies through;
i.
Protecting equipment, data, and other assets. reducing or mitigating disruptions to
operations.
ii.
Reducing damage and losses.
iii.
Achieving timely and orderly recovery from emergencies and resumption of full
service to the public
27.3 Scope
The scope of the contingency plan should cover all critical systems identified by Organisation
The contingency plan will apply in all cases of disruption of operation where the critical systems
will be affected

In order to achieve workable ICT contingency capability the Organisation should be able to
maintain a certain level of readiness and implement contingency procedures when the need
arises.
The contingency plan for Organisation shall cover all critical applications within Organisation
and shall also be updated regularly to accommodate changes in the systems.
The contingency plan shall be tested from time to time to confirm its relevancy and applicability
to the present ICT operating environment.
All staff within the ICT department shall be trained on the execution of the contingency plan.
27.5 Responsibility
Department
CIRT
ICT Operations
ICT Department
Role(s)
See detailed roles as in the Incident
Management guidelines
Ensure that all necessary mechanisms
are in place to be able to recover in case
of a disaster
Ensure that all Sections in the Unit are
able to respond to any disasters
27.6 Procedure
This procedure will be executed in conjunction with the Incident management procedures
Perform risk assessment
Define disruption Categories
Develop Risk and Impact Ratings
Identify critical ICT resources and Critical Data
Develop preparation and preventive measures
Develop preventive measures for disruption Categories
Developed essential contingency procedures
Develop notification and contingency plan activation procedures
Develop recovery strategies and plans
Test the contingency plan
Maintain contingency plan
Train the Organisation Team on the contingency plan

The detailed processes to support the steps above can be found in the Annexes detailing
the Contingency plans and incident management procedures and the
27.7 Flow Chart
Figure 13: Contingency Planning flowchart
28 Organisation/ICT/02/01/28 - IT Governance
28.1 Description
Increasingly, top management is realising the significant impact that information can have on
the success of the enterprise. Management expects heightened understanding of the way
information and communications technology (ICT) is operated and the likelihood of its being
leveraged successfully for competitive advantage.
Successful enterprises understand the risks and exploit the benefits of ICT, and find ways to
deal with:
i.
Aligning IT strategy with the business strategy
ii.
Cascading IT strategy and goals down into the enterprise
iii.
Providing organisational structures that facilitate the implementation of strategy and

goals
iv.
Creating constructive relationships and effective communications between the

business and IT, and with external partners
v.
Measuring ITs performance
Enterprises cannot deliver effectively against these business and governance requirements
without adopting and implementing a governance and control framework for IT to:
vi.
Make a link to the business requirements
vii.
Make performance against these requirements transparent
viii.
Organise its activities into a generally accepted process model
ix.
Identify the major resources to be leveraged
x.
Define the management control objectives to be considered
IT best practices have become significant due to a number of factors:

xi.
Business managers and boards demanding a better return from IT investments, i.e.,
that IT delivers what the business needs to enhance stakeholder value
xii.
Concern over the generally increasing level of IT expenditure
xiii.
The need to meet regulatory requirements for IT controls in areas such as privacy
and financial reporting (e.g., the Sarbanes-Oxley Act, Basel II) and in specific
sectors such as finance, pharmaceutical and healthcare
xiv.
The selection of service providers and the management of service outsourcing and
acquisition
xv.
Increasingly complex IT-related risks such as network security
xvi.
IT governance initiatives that include adoption of control frameworks and best

practices to help monitor and improve critical IT activities to increase business value
and reduce business risk
xvii.
The need to optimise costs by following, where possible, standardised rather than
specially developed approaches
xviii.
The growing maturity and consequent acceptance of well-regarded frameworks

such as COBIT, ITIL, ISO 17799, ISO 9001, CMM and PRINCE2
xix.
The need for enterprises to assess how they are performing against generally
accepted standards and against their peers (benchmarking)
28.2 Objective
To ensure that management is responsible for aligning ICT with business processes. Meaning
that IT delivers value, performance is measured, resources are properly allocated and risks
mitigated
28.3 Scope
The scope involves Organisation top management governance of information technology
section
A governance and control framework needs to serve a variety of internal and external
stakeholders each of whom has specific needs:
i.
Stakeholders within the enterprise who have an interest in generating value from IT
investments:
a. Those who make investment decisions
b. Those who decide about requirements
c. Those who use the IT services
ii.
Internal and external stakeholders who provide the IT services:

a. Those who manage the IT organisation and processes
iii.
b.
Those who develop capabilities
c.
Those who operate the services
Internal and external stakeholders who have a control/risk responsibility:

a. Those with security, privacy and/or risk responsibilities
b.
Those performing compliance functions
c.
Those requiring or providing assurance services

IT governance and control should meet the following general specifications:
Provide a business focus to enable alignment between business and IT objectives.
Establish a process orientation to define the scope and extent of coverage, with a defined
structure enabling easy navigation of content.
Be generally acceptable by being consistent with accepted IT best practices and standards and
independent of specific technologies.
Supply a common language with a set of terms and definitions that are generally
understandable by all stakeholders.
Help meet regulatory requirements by being consistent with generally accepted corporate
governance standards (e.g., COSO) and IT controls expected by regulators and external
auditors.
28.5 Responsibility
Roles
Head of ICT
ICT Department
Responsibilities
Shall be responsible for setting up IT
governance structures.
Reports to senior management on IT
governance issues
Implements the ICT governance standard as
outlined in the manual
28.6 Procedure
Plan and organise (PO)
This domain covers strategy and tactics, and concerns the identification of the way IT
can best contribute to the achievement of the business objectives. Furthermore, the
realisation of the strategic vision needs to be planned, communicated and managed
for different perspectives. Finally, a proper organisation as well as technological
infrastructure should be put in place. This domain typically addresses the following
management questions:
i.
Are IT and the business strategy aligned?
ii.
Is the enterprise achieving optimum use of its resources?
iii.
Does everyone in the organisation understand the IT objectives?
iv.
Are IT risks understood and being managed?
v.
Is the quality of IT systems appropriate for business needs?
Acquire and implement (AI)

To realise the IT strategy, IT solutions need to be identified, developed or acquired,
as well as implemented and integrated into the business process. In addition,
changes in and maintenance of existing systems are covered by this domain to make
sure the solutions continue to meet business objectives. This domain typically
addresses the following management questions:
i.
Are new projects likely to deliver solutions that meet business needs?
ii.
Are new projects likely to be delivered on time and within budget?
iii.
Will the new systems work properly when implemented?
iv.
Will changes be made without upsetting current business operations?
Deliver and support (DS)

This domain is concerned with the actual delivery of required services, which includes
service delivery, management of security and continuity, service support for users,
and management of data and the operational facilities. It typically addresses the
following management questions:
i.
Are IT services being delivered in line with business priorities?
ii.
Are IT costs optimised?
iii.
Is the workforce able to use the IT systems productively and safely?
iv.
Are adequate confidentiality, integrity and availability in place?
Monitor and evaluate (ME)

All IT processes need to be regularly assessed over time for their quality and
compliance with control requirements. This domain addresses performance
management, monitoring of internal control, regulatory compliance and providing
governance. It typically addresses the following management questions:
i.
Is ITs performance measured to detect problems before it is too late?
ii.
Does management ensure that internal controls are effective and efficient?
iii.
Can IT performance be linked back to business goals?
iv.
Are risk, control, compliance and performance measured and reported?
Business Goals and IT Goals

While information criteria provides a generic method for defining the business
requirements, defining a set of generic business and IT goals provides a businessrelated and more refined basis for establishing business requirements and developing
the metrics that allow measurement against these goals. Every enterprise uses IT to
enable business initiatives and these can be represented as business goals for IT. If
IT is to successfully deliver services to support the enterprises strategy, there should
be a clear ownership and direction of the requirements by the business (the
customer) and a clear understanding of what needs to be delivered and how by IT
(the provider).
Figure 1 below illustrates how the Organisation enterprise strategy should be

translated by the business into objectives for its use of IT-enabled initiatives (the
business goals for IT). These objectives in turn should lead to a clear definition of ITs
own objectives (the IT goals), and then these in turn define the IT resources and
capabilities (the enterprise architecture for IT) required to successfully execute ITs
part of the enterprises strategy. All of these objectives should be expressed in
business terms meaningful to the Organisation, and this, combined with an effective
alignment of the hierarchy of objectives, will ensure that the business can confirm that
IT is likely to support the enterprises goals
EAPHLNP Enterprise
Business Goals for IT
Direct
Metric
IT Goals
IT Scorecard
Direct
Metrics
Enterprise Architecture for

IT
Deliver
Business
Requirements
Governance
Requirements
Information
Run
IT processes
Require
Influence
Information Services
Application
(includingrespon
Imply
Information
Criteria
Need
Business Goals for IT
Enterprise Architecture for IT
Figure 14: Defining IT Goals and Enterprise Architecture for IT
Infrastructure &
people
29 Organisation/ICT/02/01/29 - IT Steering Committee

29.1 Description
Steering committee is a group of high-level stakeholders who are responsible for providing
guidance on overall strategic direction. They do not take the place of a sponsor, but help to
spread the strategic input and buy-in to a larger portion of the organization. The steering
committee is usually made up of organizational peers, and is the combination of direct
customers and indirect stakeholders.
29.2 Objective
To ensure that all ICT projects and activities are headed by a steering committee comprised of
ICT professionals and business heads tasked in providing oversight and strategic direction.
29.3 Scope
Organisation shall have an IT Steering committee responsible for offering strategic direction.
Such a steering committee shall be responsible for the following;
i.
Coordinate major IT projects within Organisation
ii.
Support key strategic initiatives within the Organisation environment
iii.
Resolve project issues and risks
iv.
Assist in commitment of organisation wide resources for ICT projects.
v.
Support and work with the head of the ICT department in improving ICT strategic
initiative
vi.
Provide a strategic interface between business units and ICT department

All planned project and active project within the ICT department shall reported to the Steering
committee.
The Steering committee shall have senior management representatives from Organisation and
the ICT Department as members.
The steering committee shall offer strategic support to IT projects that shall be brought to their
attention and portfolio.
29.5 Responsibility
Roles
ICT head
User Department
Responsibilities
Shall present ICT progress and strategies
at steering committee
Shall Nominate lead to address matter at
steering committee
29.6 Procedure
The steering committee is charged with the following responsibilities
i.
To agree an overall project plan indicating all milestones, resources and

deliverables,
ii.
To regularly monitor progress against the overall project plan,
iii.
To resolve any material issues or problems before they impact on project progress,
iv.
To endorse all major project deliverables e.g. specification of user requirements,
v.
To ensure project milestones are achieved in a timely manner,
vi.
To communicate project progress to staff in the department,
vii.
To ensure staff are properly trained in the new ways of working,
viii.
To ensure benefits are realised by the organisation.
30 Organisation/ICT/02/01/30 - ICT Procedures Management

30.1 Description
ICT Procedure management is the process of ensuring that all ICT related procedures are
adequately documented and consistently updated to reflect changes within the Organisation.
30.2 Objective
To ensure that all processes within the Organisation IT environment are identified and
documented within a procedure manual
To ensure that a relevant Guideline is developed in line with each process identified
To ensure the secure operation of ICT operations through the documentation and maintenance
of operating procedures
30.3 Scope
The scope will include the Information processing and communication facilities of the
organisations ICT Department. This Guideline addresses the definition, documentation, and
maintenance of the operating procedures for the IT environment within Organisation.

All IT operational processes shall be documented within the information technology operating
procedure manual.
Organisation Management and staff shall comply with the documented procedure manuals one
they have been documented and approved
Operating procedure and responsibilities for all Organisation ICT Department information
processing facilities should be formally documented, authorised and maintained
The Quality Assurance (Read the Quality Assurance guidelines) will consistently be reviewing
the various processes within the IT environment to identify, additional processes, process
improvement opportunities, and any processes gaps
Once identified discussion will be conducted with the affected users and department to agree on
what needs to be included in the identified process
The procedure for the process will be documented and the underlying Guidelines associated
with the procedure will be identified and documented
The new Guideline and procedure will be validated by the user and user department who will
then approve the new additional Guideline and procedure. The ICT Department will have the
final approval and the IT Guideline and procedure manual will then be updated
Training on ICT Guidelines and procedures; Quality Assurance will have the responsibility of
ensuring that user of the ICT Guidelines and Procedures are consistently updated on changes
to the Guideline and will arrange for training and awareness programs regarding the ICT
Guidelines and procedures
30.5 Responsibility
Roles
ICT Department
Users
Responsibilities
1. Consistently apply the ICT SOPS in
operations
2. Identify gaps in the ICT SOPS
3. Implements the gaps through updating
the ICT SOPs
Inform
4. Update users on changes in the ICT
SOPs
1. Comply with the ICT Department in
complying with the ICT SOPs
2. Provide feedback on usage of the ICT
SOPs
31 Organisation/ICT/02/01/31 - ICT Project Management

31.1 Description
This Guideline outlines a project management framework that promotes consistency and
improved control of ICT projects, thereby reducing risks and increasing project successes.
31.2 Objective
The purpose of this Guideline is to ensure that ICT projects are consistently initiated, planned,
implemented and closed in a manner that they deliver solutions that are within schedule, budget
and desired quality.
31.3 Scope
This Guideline applies to all ICT and other Organisation staff involved in the initiation, planning,
implementation and delivery of any type of ICT project.

All projects, regardless of size, scope or value, should be linked to business objectives.
Projects must have clear goals, scope, requirements and activity/implementation schedule
before execution.
A formal ICT project business case must be prepared for all medium to Major projects.
All projects should be designed and executed in such a manner that they produce
solutions/products that offer value-for-money.
The project initiator must seek and gain project execution/implementation approval from the
respective User / Beneficiary department head, and ICT Department.
All Projects must be fully costed and have approved budgets, prior to execution. Projects that
dont have approved budgets, must first get budget approvals, through either budget relocations
or supplementary budgets
All Projects will be assigned a Project Manager and project execution team, who will manage
the project from beginning to end/closure.
The Project Manager shall ensure that the project is managed in such a manner that keeps the
project on schedule, within budget and specified quality.
Projects must be formally documented, from initiation through execution up to closure
Any changes within the project must be formally documented and approved through a formal
change management process.
At closure, all projects must be formally handed over to the respective beneficiary department
and ICT division, will all the solution/product documentation, as well as project management
documentation.
Post implementation review, and management of Warranty, Snugs, guarantees must be carried
out after project closure.
31.5 Responsibility
Roles
User department
ICT Department
Responsibilities
1. Initiate project
2. Responsible for co-developing the project
terms of reference
3. Monitoring of project
4. Approving the project deliverables
1. Drafting the terms of reference
2. Implementation of the ICT project
3. Monitoring the project implementation
process
31.6 Procedure
Identify the Business need / requirement that needs to be fulfilled
Design and define high level solution that provides a solution to the business requirement. This
will clearly identify business goals, scope, requirements and deliverables.
The Project Initiator shall develop a Project Initiation Document which will be approved by the
Accounting Officer in conjunction with the Head of the User/Beneficiary department. A Project
Manager will be identified and appointed.
The Project Manager will develop a project implementation activity schedule, with resource and
related costs. This will be approved by the Project Sponsor represented by the ICT director and
Head of User department.
The Project Manager will ensure the project is implemented according to schedule, budget and
desired quality/set of deliverables. Any changes will first be approved through a formal change
management procedure.
Once all activities have been performed, the Project manager will test for completeness and
document all project activities.
The project manager will then handover and close the project.
This procedure shall be read in conjunction with preceding project management procedures
31.7 Flow Chart
Figure 15: ICT Project Management Flowchart
32 Organisation/ICT/02/01/32 ICT Project

Conceptualization and approval
32.1 Description
Project conceptualisation refers to the inventing or contriving an idea or explanation and
formulating it mentally. Within project management it is when ICT project ideas are developed.
Within Organisation project conceptualisation will be the process of developing and justifying
project ideas.
32.2 Objective
To ensure that all potential project concepts are supported with a background of sufficient
research information justifying their viability and feasibility to ensure that Organisation invests in
ICT projects with acceptable return on investment and such project shall impact Organisation
positively.
32.3 Scope
The Guideline shall apply to all ICT projects that include;
Software,
i.
Proposal for changes to existing software
ii.
Acquisition of new software
iii.
Development of new software
Hardware
iv.
Acquisition of new hardware
v.
Upgrade of existing hardware
Network related projects.

vi.
Acquisition of new network equipment.
vii.
Upgrade of existing Network

All ICT project concepts shall be subjected to comprehensive research to ensure that they are
viable, feasible and are in support of the strategic direction of Organisation.
Only projects with approved concepts or business cases shall be allowed to proceed
Project conceptualisation shall include the following activities;
1. A feasibility study shall be conducted for proposed ICT Project .Such a study shall be
jointly carried out with the business unit or department requesting the ICT Project, and
the Organisation study projects and total quality management.

2. The project concept shall include the purpose of the ICT project and the expected
benefit as a result of the ICT Project
3. The expected benefit should be qualitative and quantitative in nature.
4. A business case shall be the end result and shall be escalated to the ICT Department
and the Head of the user department for approval. A business case shall be conducted.
The business case form shall include;
i.
Purpose of ICT project
ii.
Benefit
iii.
Scope of the system
iv.
Whether its not covered in another systems
v.
High level functionality
vi.
Clear definition of the product, service or outcome of the concept.
vii.
Problem statement to justify the concept.
viii.
Costs benefit analysis of the concept.
ix.
Political, Economic, Social and Technological (PEST) analysis related to the

concept.
x.
Projected return on investment on the concept.
xi.
Resources required (Finance, Human, Time, etc.) to support the concept.
5. The project concept shall be presented to the IT Steering committee for approval before
commencement
32.5 Responsibility
Roles
User department
Responsibilities
1. Providing need for a project
2. Feasibility study for project concept
3. Seeking approval for project concept
5. Obtaining resource commitment for the
project
ICT Department
1. Assist in feasibility study

2. Co-approval of the project t
32.6 Flow Chart

Figure 16: ICT Project Conceptualization and Approval flowchart
Reference Flow Chart

Guideline Name
Organisation/ICT/02/01/33
Flow Chart Reference
ICT Project
R.1
Planning
33 Organisation/ICT/02/01/33 ICT Project Planning

33.1 Description
Project planning refers to the outline of project resources and activities for the duration of the
project. It helps to outline how the project will be achieved and identify the requirements of the
project
33.2 Objective
All ICT projects shall be subjected to project planning (First objective ends here). To ensure that
there is adequate allocation of resources such that projects are completed within time, budget
and within acceptable quality standards.
33.3 Scope
All ICT projects in the Organisation annual business plan shall be subjected to a formal project
planning process

All projects shall have an adequate planning phase and the following shall be included in the
planning phase.
1. Development of a project plan with clearly outlined timelines, milestones and resourcing
to perform the tasks.
2. Development of a project charter to govern the project
3. Forming a steering committee and a project team assembled and approved.
4. Project risk and issues shall be identified and documented early in the project.
33.5 Responsibility
Department
ICT Department
User department
Role(s)
1. Develop project terms of reference
2. Assigning of project team members
3. Develop project plans
1. Nominate project team members
2. participate in project planning
3. Approve project plans
33.6 Procedure
In the project planning stage of the organisation should develop a project team structure which
shall decide what resources to use
The project initiators will develop terms of reference for the project team staff.
A project charter shall be developed outlining the key governance aspect of the project as well
as include the project plan
The project charter will be signed by the user department and the ICT department
representatives
33.7 Flow Chart
Figure 17: ICT Project Planning flowchart
34 Organisation/ICT/02/01/34 Project Implementation

monitoring
34.1 Description
Project implementation monitoring is key to ensure that the project is being implemented
according to set out standards and to ensure that it is being implemented according to the set
out plans
Effective project management should include supervision and quality assurance throughout the
project life cycle.
Project implementation follow up should cover the following.
i.
Tracking of the project plan to ensure that the project team members are working
within the budgeted time and conditions.
ii.
Quality control of the project deliverables at each phase to ensure that they are
being implemented in accordance to the project standards.
iii.
Confirm that all the necessary test and quality assurance activities are being
performed efficiently.
34.2 Objective
To ensure that the project is being managed consistently according the approved approach and
standards.
34.3 Scope
The scope covers all the ICT projects within Organisation

All Organisation ICT project shall be subjected to continuous monitoring and evaluation.
All projects shall be subjected to periodic monitoring.
Project monitoring activities shall be included in the planning stage of the project and not project
plan shall be approved without the monitoring aspect as activities.
The Quality Assurance will be expected to be fully conversant with the project activities and
deliverables and where there is knowledge gap a training is conducted to ensure that that
effective monitoring of the project performed.
34.5 Responsibility
Role
ICT Department
Steering Committee
Responsibility
Ensure teams are constituted to handle the projects and
approvals are given in a timely manner
Ensure that work on projects is well documented and the
projected Is carried out as prescribed in this manual
34.6 Procedure
Project implementation monitoring shall be the responsibility of the project team, and
Organisation study projects and total quality management.
Project monitoring will be done by the Quality Assurance through review of the activities being
performed by the project manager outlined in the planning phase of the project
Monitoring will shall be performed by the Quality Assurance team through consultation with the
user department to confirm whether the deliverables are being issued as agreed in the planning
stage throughout the project cycle
Monitoring will also be performed by the Quality Assurance member on delivery if the ICT
project to ensure that the deliverable are of the expected quality and that the solution is
sustainable.
In the course of the project monitoring progress reports shall be issued by the project manager
as part of project control and the Quality Assurance members shall also develop project
monitoring report with input from the project manager in order to provide an independent view of
the project.
34.7 Flow Chart
Figure 18: Project Implementation Monitoring flowchart
Guideline Name
Flow chart Reference
ICT Project
R.1
Planning
R.2
Organisation/ICT/02/01/35 Project Closure,
Sign-off
35 Organisation/ICT/02/01/35 Project Closure, Sign-off and

Retention of project documentation
35.1 Description
Project closure and sign-off is a formal process of winding up a completed project. It helps the
project in accounting for the activities and the deliverables
35.2 Objective
To confirm and approve the final project deliverables and officially close the project
35.3 Scope
The scope covers the entire ICT projects within Organisation

All project much come to an end either through abortion or completion and in all cases a project
closure processes and sign- off shall be conducted and completed.
All completed project must be officially signed off by the project manager and representatives of
the steering committee.
All projects must come to an end after all the deliverables have been delivered and accepted by
the project requester or user
All project deliverables resulting from the project shall be recorded and archived in line within
the documentation retention polices of the organisation and shall be stored in-line with country
specific regulations on document retention
35.5 Responsibility
Role
Designated project manager
Steering committee
Responsibilities
1. Ensure that all project deliverables are
completed
2. Seek approval for all completed
deliverables
3. Store completed project deliverables
4. hand over deliverables.
Approve and sign off completed
deliverables.
User department
3. Approve and signoff deliverables
35.6 Procedure
The project closure procedure shall commence with the delivery and handover of the project
final deliverables to the user and/or user department.
Upon the user department testing and accepting the deliverable(s), a sign-off of the
deliverable(s) shall be made by the head of the user department or a rejection of the deliverable
will be made resulting in rework on the deliverable(s) if unacceptable.
The project closure and sign off process should include the following
i.
Report on the variance between baseline project plan and final project plan.
ii.
Report on the variance between baseline budget and final budget
iii.
Lessons learnt from the project.
iv.
Acceptance of the project deliverables
v.
Documentation of any issues outstanding
vi.
Documentation of project risks
vii.
Return on investment evaluation
Procedure for documentation resulting from project shall include the following
i.
ii.
iii.
iv.
v.
The project manager shall compile all documentation from the project and this
documentation shall include the following
a. Project plans
b. Documentation on all project deliverables
c. Issues log
d. Risk logs
e. Lessons learned reports
f. Project status report
g. Project budget baseline and final budget
The project manager shall copy any back-up all the soft copy documentation to an
electronic media such as CD, DVD, Data Tape. Where possible all hard copies of the
documentation shall be scanned and also backed up on electronic media.
In cases were an document management system exists the electronic form of
documentation shall be added to the electronic document management system for
reference and archiving
All hard copy documentation such as signed off files and documentation shall be
compiled and indexed and archived using the organisation archiving procedures and
stored securely in the organisation archives and records for future reference.
All documentation resulting from a project shall be stored in line with documentation
retention laws of the country at a minimum and where the organisation may require the
documentation archived for more than the country minimum retention period the project
manager shall clearly document the retention period for all hard copy and soft copy files
of the respective project.
35.7 Flow Chart
Figure 19: Project Closure, Sign-off and Retention of project documentation flowchart
Section
Reference
33
Guideline Name
ICT
Project
R.1
Project
R.2
Planning
34
Implementation monitoring
36 Organisation/ICT/02/01/36 Project Documentation and

Retention
36.1 Description
Project documentation is important for creating a record of organisation ICT projects activities. It
is an activity that will help the organisation to build knowledge and to organise the knowledge.
Retention is the time interval that documentation related to projects should be kept within the
organisation.
36.2 Objective
To ensure the all project documentation is formally documented and stored in a safe and secure
environment for purposes of future references and retention period and must be in accordance
with the laws of the country and organisation guidelines on retention.
36.3 Scope
All documentation that will be generated as part of ICT activities covered in this Guideline.

All activities and projects within ICT shall be documented throughout the life cycle of the
activities or projects.
For each activity or project formal documentation shall be designed, completed and stored in
electronic format using the back-up Guideline.
Where physical documents are generated as part of the ICT projects or activities the physical
hard copy documents shall be scanned and copied and stored in an electronic format for
reference.
All hard copy documents that cannot be stored within the ICT department shall be stored in the
archives facilities for the organisation.
On project closure in line with the standards for project management all project documentation
shall be reviewed and stored in an electronic format for future reference
The retention period for the documentation shall be in accordance with the national guidelines
on documentation retention.
36.5 Responsibility
Roles
ICT Department
User Department
Project managers
1. Collect all project document
2. Archive all project documentation in
accordance
with
the
laws
of
documentation retention
1. Retain the project documentation as
prepared by the project manager
36.6 Procedure
On commencement of each ICT project activity an electronic file or database shall be created to
store all project information.
The electronic file shall be scheduled for regular back up in line with the backup Guideline.
Once the activities or project have been concluded the project manager or team leader of the
project will be requested to take a stock of all project documentation from the project members
and this project information shall be stored within the electronic project file for final back up.
Hard copies shall be scanned and copied into the electronic file and the original hard copies
stored securely in line with retention Guidelines for the country and organisation.
.
37 Organisation/ICT/02/01/37 Quality Assurance at

Acquisition
37.1 Description
This Guideline would ensure that quality standards are observed by all Organisation IT
department personnel when they acquire and introduce new hardware and software into the
Organisation operating environment.
37.2 Objective
To ensure that quality standards are implemented when acquiring computer hardware and
software for usage within the Organisation environment.
37.3 Scope
This Guideline applies to the acquisition of new hardware, networking and software within
Organisation ICT environment

All software, hardware and network equipment that shall be acquired and installed in the
Organisation environment shall be compliant with the user requirements.
All off-the-shelf software, hardware equipment and network equipment shall be acquired from
reputable ICT companies with verifiable references and the same Organisation must comply
with procurement regulations of Organisation.
The acquisition process of all ICT related project, services, equipment must be compliant with
quality standards for Organisation.
A quality assurance officer shall be appointed in the organization who shall be responsible
for quality assurance of ICT projects and shall work with all the respective departments and
persons in the project as stipulated under the responsibilities section.
37.5 Responsibility
Roles
ICT Department
Quality Assurance
Responsibility
1. Confirm terms of reference
2.
ensure implementation of quality
standards in the acquisition process
3. Address any recommendation from
quality assurance
1. Confirm terms of reference
2. Check compliance with quality
standard and stated in the guidelines
3. Report on findings
37.6 Procedure
The following quality standards should be considered for hardware and software
All software should comply with the software Guideline procedures in furthermore all software
should include the following;
For all acquired software there must be requirements specified by the user department which
will be signed off and approved
All off the shelf software identified for acquisition should satisfy user requirements and should
ensure minimal customisation where possible.
i.
Vendors for off the shelf software should have implemented successfully the
software in at least three sites successfully and the reference sites should be
verifiable.
ii.
The vendor should be able to offer support for the software post the implementation
of the software.
iii.
All software applications should have a licensing agreement that is consistent with
the licensing Guideline
iv.
All software acquired should be compliant with the software testing procedures in
Annex
v.
A knowledge transfer plan should be developed and approved in the acquisition

process to ensure that internal staff develop the capacity the support the software.
vi.
An implementation methodology should be developed and approved in acquisition

of the software.
vii.
Software should be compliant with the current hardware specifications and

standards and any additional hardware that is not compliant with the present
standards should first be evaluated and formally approved by the by the ICT
Department
Hardware and network equipment -All Hardware should comply with the Hardware Guideline
procedures, furthermore all hardware should include the following;
viii.
For all acquired hardware there must be requirements specified by the user
department which will be signed off and approved
ix.
All hardware should have a warranty for a specified period of not less than 1 year.
x.
All new hardware and network equipment should be compliant with the minimum
baseline standard
xi.
Only approved hardware and network equipment brands should be considered.

Acquisition of non-approved brands should not be allowed and approval for their
acquisition should be through ICT Department
xii.
All hardware and network equipment should be compliant with the software
requirements in cases where it shall host specific software(s).
xiii.
All hardware and network equipment should carry a seal for quality to confirm
quality standards in the assembly as well as quality control checking.
xiv.
All hardware and network equipment should be acquired from approved local and
international suppliers from Organisation as well as the hardware manufacturer.
xv.
Knowledge transfer plan should be developed and approved in the acquisition

process to ensure that internal staff develop the capacity the support the hardware
and network equipment.
Develop a quality plan that will be used to review the acquisition process based on all the items
within this guideline.
37.7 Flow Chart
R.1
R.1
R.2
R.3
R.2
NO
1
Review
requirements
Refer concerns to
Supplier and
project team
NO
NO
2
Requirements
met?
Yes
11
Is vendor
approved?
YES
10
Is it software?
NO
9.
Refer to supplier
No
5.
Is an approved
brand?
3
Is hardware or
network device?
YES
Yes
12
Does vendor have
credible reference
4
Is it an approved
Vendor?
YES
Yes
6
Was it quality
checked ?
NO
YES
NO
YES
15.
Approve Quality
15.
Does vendor offer support
post implementation ?
YES
7
Does it have
warranty ?
YES
YES
16.
Issue Quality
Repor
8
Does it comply with
minimum baseline
standards
14
Vendor uses approved
implementation
methodology ?
R.4
Figure 20 : Quality Assurance at Acquisition flowchart
Guideline Name
General Software Guideline
Organisation/ICT/02/01/Annex
Design
Hardware and Network
NO
Flow Chart reference

5
Solution
R.2
R.3
38 Organisation/ICT/02/01/38 Quality Assurance at

installation/implementation
38.1 Description
Quality should be observed at implementation of ICT project as well as installation of computer
hardware and network equipment.
38.2 Objective
To ensure that the installation or implementation of hardware and network equipment and
Software is compliant with Organisation Guidelines and quality standards
38.3 Scope
This applies to all software, network and hardware projects.

The implementation and installation of Software, hardware and Networks shall be compliant with
the hardware Guideline, software Guideline and ICT project management Guideline
A quality assurance officer shall be appointed in the organization who shall be responsible
for quality assurance of ICT projects and shall work with all the respective departments and
persons in the project as stipulated under the responsibilities section
38.5 Responsibility
Department
Project manager
Quality Assurance
Role(s)
1.Implement the project using quality
assurance guidelines
2. Implement quality recommendations
1. Review the implementation process
compliance to quality standards.
2. Monitor the implementation process
3. Issue quality recommendations
38.6 Procedure
Installation and implementation of new hardware, network and software should be compliant
with the project management standards and approach as specified in the hardware and
software Guideline.
The following should be considered;
i.
A quality plan should be developed and referenced in the implementation process
and quality plan should be approved by the ICT Department.
ii.
Quality assurance should be deployed at all stages to ensure that the standards are
maintained at all times.
iii.
Only approved and competent team members should be in the implementation

team.
The Quality Assurance shall ensure that the implementation of the ICT project is in line with the
various Guidelines related to software, hardware and Network within Organisation and where
there are variations flag all the issues to the ICT Department and the project responsible
38.7 Flow Chart
Figure 21 : Quality Assurance at installation/implementation flowchart
Guideline Name
General Software Guideline
Organisation/ICT/02/01/Annex
Design
Hardware and Network
Solution

R.1
R.2
R.3
39 Organisation/ICT/02/01/39 Research & Development

39.1 Description
Research and development refers to creative work undertaken on a systematic basis in order to
increase the stock of knowledge, including knowledge of man, culture and society, and the use
of this stock of knowledge to devise new applications".
Research and development is often scientific or towards developing particular technologies and
is frequently carried out as corporate or governmental activity.
Research and development within Organisation shall be used to improve the ICTs within the
organisation and the following shall be considered in the R&D.
Consistent reviews of the information communication technologies needs related to the
Organisation core business and identify the most suitable information communication
technologies applicable to Organisation and the requirements of people and processes within
Organisation.
Processes re-design proposals to ensure that the Organisation ICT department is more efficient
and consistent with its strategic plan.
Invest in knowledge related to ICT for utilities and ensure that a knowledge base is created for
use by the ICT department and organisation as a whole.
Deliberately invest in understanding the challenges within the Organisation ICT department,
record the challenges and develop alternative solution options for each challenge to the various
section heads and head of ICT departs.
Assist in the development of new products and services for Organisation
39.2 Objective
To ensure that Organisation invests in building knowledge related to information communication
technologies resulting in the development and enhancement of processes, procedures,
information systems and IT infrastructure
39.3 Scope
The Guideline shall cover the following
All ICT processes and information communication technologies.
ICT enables process and general processes within Organisation.

The Quality Assurance should have the capacity to provide knowledge related to the various
ICT projects within Organisation.

The Quality Assurance should invest in knowledge and develop a knowledge repository for all
the projects past, present and upcoming and such knowledge will used to develop enhance ICT
project and processes.
39.5 Responsibility
Roles
ICT Department Research team
Responsibilities
1. Identify key research areas
2. Approve research areas
3. Perform research
5. Publish research results to department
and running projects
39.6 Procedure
The research development function shall be key in providing knowledge to ICT project and
procedures. The following procedures shall assist in the research and development within
Organisation.
The organisation study projects and total quality management team shall develop and maintain
an inventory of the past, present and planned project in Organisation.
The organisation study projects and total quality management team shall record all the issues,
ICT projects and risks within Organisation that may require and ICT based solution.
Deliberate research will be conducted by the organisation study projects and total quality
management team on the issues, risk and ICT project and such research will include internal
knowledge and external knowledge that includes secondary research from reputable knowledge
sources.
The findings from the research will be communicated to the various user departments , ICT
projects and ICT department management for consideration in the Organisation improvement
plans. Periodically the Quality Assurance will also review the Organisation business plan and
identify areas of improvement in relation to the research and such communicate to the ICT
Department and the head of the various departments including the Director General
Organisation.
39.7 Flow Chart
Figure 22: Research & Development flowchart
40 Organisation/ICT/02/01/40 Training
40.1 Description
Training is a fundamental aspect of enhancing skills within the Organisation and this Guideline
will aim to address training key areas within the Organisation.
40.2 Objective
To ensure the Organisation staff and third parties receive relevant training on aspect related to
ICT operations such that capacity is developed and maintained.
40.3 Scope
All employees and third parties that access Organisation communication systems and
computing platforms

All training shall be in compliance with the Human Resource Guideline and procedure manual
on training.
All personnel shall be required to be trained first before they operate, configure or install IT
hardware and Network equipment and software.
40.5 Responsibility
Roles
Responsibilities
Human Resources
1. Maintain the HR Training policies

2. Ensure all needs assessment are
being addressed.
ICT Department
1. Develop training needs assessment

2. Develop training program.
3. Seek approval of training plans from
Human resources in accordance with the
HR guidelines
4. carry out training
40.6 Procedure
Access Guidelines
i.
Organisation should create procedure for training all employees and other users on
how to access and use its communication systems. Each employee should
understand what areas are acceptable and what areas are not to be accessed. All
employees should be trained on access controls and legal responsibilities. All
employees should be aware and remain vigilant for possible fraudulent activities.
Well defined procedure should be in place in order for employees to report incidents
involving their personal accounts or the acts of others.
Software Packages
ii.
Training should be conducted on the acceptable use of all software used for
communication with other systems and personnel. All applications should have a
logon process with a secure method of password protection. Guidelines and
procedure are to be developed and delivered in a training arrangement with all
employees.
New Systems
iii.
All users should be trained on the use of new systems. The level of Information
Security training required for individual system users must be appropriate to their
specific duties, so that the confidentiality, integrity, and availability of information
they would normally handle is safeguarded.
Technical Staff
iv.
Information Security staff both protects the information asset, but equally, may
inadvertently (or maliciously) put it at greater risk. Therefore it is essential that they
be trained to a level of competence in Information Security that matches their duties
and responsibilities.
Incident Reporting
v.
A process for reporting incidents and concerns should be communicated to all

employees so they can communicate breaches and all other suspicious activities to
the appropriate levels in the organization.
Organisation ICT Department

vi.
Organisation ICT Department is to have resources that oversee the operation with
respect to all forms of Information Security. This resource shall be responsible with
safeguarding all information asset, measuring effectiveness, providing
countermeasures, and development of training and awareness programs.
40.7 Reference
Quality Assurance Guideline
40.8 Flow Chart
41 Organisation/ICT/02/01/41 Web Application development,

Hosting and Content
41.1 Description
The EAPHLN Project aims to establish a network of efficient, high quality, accessible public
health laboratories for the diagnosis and surveillance of Tuberculosis (TB) and other
communicable diseases. As such a Web Portal has been developed for purposes of sharing
information about the project using the URL -http://www.eaphln-ecsahc.org/. As such it is
important that the process of developing web applications, hosting and content publication is
adequately managed to ensure that the Web Application is managed consistently.
This Web Application Guideline shall be read in conjunction with the detailed Guideline in Annex
I, Annex II, Annex III, Annex IV and the General Software Guidelines.
41.2 Objective
To ensure that all Web Applications or Websites are developed and Managed in a controlled
manner by all the ICT TWG members and Partner states who are responsible for creation and
managing the content.
41.3 Scope
The scope of this guideline and Procedure shall cover the Web Application or Website
development, Hosting and Content Publication.

All EAPHLN Web portal development must be done in-line with the principles and guidelines of
software development as defined within these ICT Standard operating procedures.
All content creation and publication shall be performed by designated Webmaster(s) whom shall
be recognised and approved by the EAPHLN ICT Technical Work group.
All web content shall be reviewed and signed off before being uploaded and shall be in
compliance with the change management guidelines and procedures within this manual
The content of the web portal shall ONLY promote the objectives and goals of the EAPHLN
Project. The Webmaster shall monitor and ensure that all content does not include the following;
I.
II.
III.
IV.
Abusive statements that are against the objective and goals of the EAPHLN
Viruses and embedded Spam
Advertisement of services of other organisations
Poor formatting of content that makes it difficult to view
The Web Portal shall have a service level agreement with an Internet service provider and the
service level agreement shall be compliant with the guidelines and procedures related to
Network configuration, network access, third party network access.
The Web Portal shall be updated frequently with current content. The content on the Web Portal
shall be reviewed by a ICT TWG before publishing.
The Web Portal shall comply with the respective cyber laws of the EAC partner states.
41.5 Procedure
Web Development
1. Web development shall follow the guidelines and procedures of software development
and security requirements detailed in Annex I, Annex II, Annex III, Annex IV and the
General Software Guidelines.
Web Hosting
2. The EAPHLN Web Portal shall be hosted on the internet in the public domain and shall
use the following URL http://www.eaphln-ecsahc.org.
3. When hosting, a service level agreement shall be put in place with the internet service
provider.
4. The Webmaster shall ensure that the internet service provider is in compliance with the
service level agreement or contract at all times and shall review performance of the
hosting services and consult with the ICT TWG for any amendment to the contract or
service level agreement to improve value of the service.
5. The Webmaster shall also confirm whether the ISP does not present a security risk by
testing compliance with the security related guidelines and procedures of the
organisation and work closely with the IT security team to identify any potential security
weaknesses and breaches.
Content
1. The designated Webmaster shall keep track of all relevant news, information, images,
statistics regarding activities and projects within the EAPHLN.
2. The Web Master shall request for potential content in the form of pictures, reports,
information, project updates from the various user departments.
3. All the potential content shall be reviewed by the Web Portal committee based on a
criterion they shall set.
4. All approved content shall be handed over to the Web Master who shall upload the
content based on the categories in the Web Portal.
5. The Web Master shall follow change management guidelines when applying any
changes or updates to the Web Portal.
6. All non - current content shall be moved into archives based on a criteria set by the ICT
TWG, and a decision will be made to include the archiving of the content within the
portal or store the content outside the portal.
7. The Web Master will review all the content after posting new content to confirm
consistency, user friendliness of navigation and also confirm that there are no dead links
or links that do not lead to the right content or errors.
41.6 Responsibility
Roles
Responsibilities
ICT TWG
1. Approve all web content and technical

changes
Web Master
1. Co- development and maintenance of

the website.
2. Work with the Internet Service
providers to ensure all hosting is
performed in accordance to requirement
3. Update approved content on the
website
42 ANNEXES
43
Organisation/ICT/02/01/Annex 1 - Contingency Plan for

Laboratory Information Systems(LIS), Health information
Systems(HIS)
43.1 Background
The key aim of Organisation ICT Contingency Plan (Contingency Planning) is to assist in
preventing, where possible, events which disrupt the Organisations business operations and
services, and to minimize the potential impact of any unavoidable disruption by containing it to a
predictable and pre-determined acceptable period of time.
In preparation of this plan, consideration has been given to the possibility that implementation
and execution of specific phases of the plan may be required by individuals with limited prior
knowledge and exposure to the details of the entire plan. Therefore, the approach taken in the
plans development was one with particular focus on the following:
i.
Heightened awareness of management and employees to disasters and their
impacts;
ii.
Advanced preparation to minimize impact potential; and
iii.
Training of staff in the execution of pre-defined responsibilities and tasks.
The Organisation recognizes and acknowledges that the protection of its assets and business
operations is a key responsibility to its employees, shareholders, business associates, and other
communities that it serves. Therefore, The Organisation seeks to establish its viable
Contingency Plan.
The Organisation is committed to supporting resumption and recovery efforts at alternate
facilities, if required. The Organisation and its management are responsible for developing and
maintaining a viable Contingency Plan that is consistent with the provisions and direction of the
Organisations strategic and tactical plans.
The Organisation mandates the existence of a Contingency Plan that fully supports the
philosophy of providing and maintaining the highest quality services to its customers and
employees
43.2 Scope
The primary objectives of the plan are:
i.
Provide the Organisation with a plan that will help in an efficient, effective and timely
recovery and resumption of the interrupted ICT Operations affecting the LIS and HIS
ii.
Ensure recovery of LIS and HIS within the timeframes specified by the various
business units;
iii.
Minimize the inconvenience and potential disruption to customers and employees;
iv.
Prevent Organisation from sustaining financial and operational impacts that could
seriously jeopardize the Organisation;
v.
Ensure that any potential damage to Organisations reputation or image is averted

and protect the public image and confidence in the Organisation;
vi.
Resume and maintain adequate service levels to end users;
vii.
Resume operations and support of all critical IT functions within the time frame
specified by the business units;
viii.
Provide a proper work environment for the displaced staff while the primary site and
its set-up are in the process of restoration; and
ix.
Ensure that normal business operations at the primary site or other alternate sites
are restored in a timely manner
The Contingency Plan seeks to minimize the following:

x.
The number and frequency of ad hoc decisions made following a disaster.
xi.
The Organisations dependence on the participation of any specific person or group

of persons.
xii.
Need to develop and implement new procedures during recovery, response,

resumption, and restoration.
xiii.
Loss of data and information, recognizing that the loss of some data and information
is inevitable.
xiv.
Confusion and exposure to errors, omission, and unnecessary duplication of effort.
xv.
The extent of losses associated with an extended recovery operation.
xvi.
The total elapsed time required for completing the recovery, response, resumption,
and restoration
43.3 Approach
Organisation should employ the following approach to accomplish the contingency planning
objectives:
i.
Prevention by improved employee awareness and preventive controls.
ii.
Impact minimization by advanced preparation of pre-qualified strategies and

resources.
iii.
Controlled response by definition and pre-assignment of recovery responsibilities by

team and task.
43.4 Key Steps in Recovery Process

Readiness actions are the activities to be performed to ensure that the Organisation is ready to
meet any contingency / disaster. These are in the nature of preparatory actions for readying the
required facilities and purchase and set up of hardware systems and telecommunications
facilities to be used during a disaster.
The main steps to be undertaken in the recovery process are provided below:
43.5 Contingency plan
Systems are to be maintained at High availability site with online real-time replication with no or
very low (less than 5 minutes) time delay. Systems are also to be maintained at the DR site
with online replication of data with time delay (maximum time delay of 8 hours).
In order to ensure a viable recovery using backup tapes, it is important that copies of the backup
are stored at a secured off-site location within the country for local recovery. The tapes should
be retrievable from this location within a few hours for restoration in the event of a crisis
43.6 Contingency planning team responsibilities

Pre-Disaster
i.
Understand role and responsibilities within the Contingency Plan
ii.
Work closely with other Teams to ensure all LIS and HIS are available off-site along
with other relevant information such as configuration details, license certificates,
technical and operational documentation and vendor support contact information
iii.
Work closely with other Teams to reduce possibility of a disruption to critical

business applications
iv.
Provide hardware sizing requirement to hardware team
v.
Participate in Contingency Plan tests as required
Post-Disaster
Platform
vi.
Coordinate restoration of standalone operating systems onto the main servers
vii.
Coordinate restoration of network operating systems
viii.
Ensure the security Guideline of the network operating system is adequate and
appropriate with relevant controls configured to authenticate and authorize users
access to network resources
ix.
Ensure that the active directory is set up appropriately with the required group and
individual privileges and services for effective and secure access
x.
Assess the operating system for system and data integrity before release to end
users
xi.
Update the Contingency Planning Lead Team Leader on the status of platform
recovery and availability at the alternate site
Applications
xii.
Coordinate restoration HIS and LIS applications and data which are critical to end
users and business operations as a whole
xiii.
Follow documented procedures to recover all application files to a point-in-time as

close to that of the event as possible
xiv.
Assess the applications for system and data integrity before release to end users
xv.
Ensure backups of applications and data are scheduled once the alternate site is
active
xvi.
Update the Contingency Planning Lead Team Leader on the status of application
recovery and availability at the alternate site
End User Software

Coordinate restoration of end user software such as desktop operating system, office and mail
applications and other tools and utilities required by users to perform the day-to-day business
operations.
Ensure that a standard pre-approved loadset comprising of applications, tools and utilities is
maintained and restored onto end user systems for recovery at the alternate site
Update the Contingency Planning Lead Team Leader on the status of recovery and availability
of end user applications at the alternate site
Assess the software for system and data integrity before release to end users
43.7 Incidents
Having a Contingency plan is taking measures to prevent a disaster or to mitigate its effects
beforehand. This portion of the plan reviews the various threats that can lead to a disaster,
where our vulnerabilities are, and steps we should take to minimize our risk. The threats
covered here are both natural and man-made.
Force Majeure
Force Majeure refers to risks caused by acts beyond human influence, for events
outside of human control, such as sudden floods or other natural disasters, for which
no one can be held responsible to; fire in the Computer Room, especially in the server
room area, earthquakes, floods, lightening
Application / Operating Systems Failures
The threat of application and /or operating systems failure affects all the three
systems in question and is a very possible and imminent threat. This could be caused
by virus attacks, buffer overflows, configuration errors, human errors and sudden
power outages.
Links and Network Failures
These pertain to failures that arise when links or the network is down. Given the
centralised nature of the systems mentioned, it is imperative that links are always
available. Link outages can be caused by Service Provider failures and / or inefficient
infrastructure.
Hardware Failure
The threat of hardware failure pertains to server outages where hardware breaks
down. This can be caused by lack of preventive maintenance, obsolete equipment
and accidental damage.
This threat poses an impact on three systems as it can cause inaccessibility of the
systems to the Organisation.
Data Corruption & Database Failure
All the systems in question use centralised databases. They are therefore susceptible
to data corruption and database failure. The impact of data corruption is loss of data
integrity, financial loss resulting from lost data, impairs decision making and opens up
Organisation to fraud. Data corruption and Database failure can be caused by
malicious staff, poor database backup and turning procedures, virus attacks,
exposure to magnetic fields and careless mistakes.
Power Failure
The threat of power outages in particular causes disruption in normal operations and
can lead to Hardware breakdown, data corruption, OS corruption, etc. Because it is
the commonest threat to all the three systems by virtue of its frequency, there is need
to address it very particularly.
43.8 Scenarios
These options, detailed below, are not alternatives and the Organisation will need to implement
all of these scenarios to ensure effective Contingency.
Incident or Threat: Force Majeure
Impact: a. Primary data center unavailable
b. Critical people at primary site unavailable
Scenario 1 (Plan A): Use DR Resources
Recovery: Attempt recovery by activating the recovery site and use
resources (facility / data center / backup personnel) from there. The alternate
location would have pre-established connectivity with the data center setup at
the primary site and users would be able to access HIS and LIS applications
there as soon as they have been restored / updated and brought online.
Scenario 2 (Plan B): Rebuild Applications and recover from Backup

Recovery: Rebuild the application servers and recover data from external
backups, e.g. Tapes and external hard disks. This would arise if the DR site
has also faced the same incident as the primary site.
Incident or Threat: Application / OS Failure
Impact:
Service)
Application Unavailability at Primary Data Centre (Denial of
Scenario 1 (Plan A): Switch to Backup Server

Recovery: Bring online backup server in the same location (primary data
centre) and let it assume the same IP address/name as the offline server
Scenario 2 (Plan B): Switch to Back up Server at DR Site
Recovery: Should there not be a backup server at the primary site or should
the outage have affected the backup server as well, bring the server at the DR
site online and redirect user traffic to the DR site server.
Scenario 3 (Plan C): Rebuild Server at Primary Site

Recovery: If for any reason, it is not possible to use the Backup server at the
DR site, rebuild the servers at the primary site and recover from backup tapes
or any other external backup media.
i.
Install the OS from CDs, include antivirus, etc. as applicable
ii.
Install the application (HIS or LIS)
iii.
Restore the application Database
iv.
Restore the data into the Database using external media (tapes, hard
disks, etc.)
v.
Connect to the network and go live
Incident or Threat: Links and Network Failure

Impact:
Offsite branches cannot access real-time data or process
transactions
Scenario 1 (Plan A): Use Alternative Links
Recovery: Switch from the affected service provider to another (activate the
alternative link) or use the Organisation fibre where applicable
Scenario 2 (Plan B): Use offline Mode
Recovery: If both links (primary and secondary are down), advise users to
use offline mode of the systems until services are restored.
Incident or Threat: Hardware Failure
Impact:
Primary data server unavailable

Recovery: redirect traffic to DR site to ensure continuity of operations
Scenario 2 (Plan B): Repair/ Replace Faulty Hardware
Recovery: Should the DR site not be available, repair or replace the faulty
part of the hardware and bring the server back online.
Scenario 3 (Plan C): Acquire New Hardware and rebuild System
Recovery: If it is not possible to repair the faulty part of the system, acquire
new hardware and rebuild the machine. Use steps prescribed above.
Incident or Threat: Data Corruption and Database Failure
Impact:
Loss of Data and Loss of Data integrity
Recovery: redirect traffic to DR site to ensure continuity of operations
Scenario 2 (Plan B): Restore from External backup media

Recovery: Should the DR site not be available, restore data from external
backup media (e.g. Tapes, external hard disks, etc.). Perform restoration tests
to ensure data is complete.
Scenario 3 (Plan C): Reconfigure Database from Manual Data
Recovery: If it is not possible to use the DR or to restore using external
backup media, rebuild the system and reconstruct data from manual records
up to the last available data.
Incident or Threat: Power Outages
Impact:
a. Primary data Centre unavailable

b. DR Site unavailable
Scenario 1 (Plan A): Use Alternative Power

Recovery: Switch on alternative (backup) power sources (e.g. Solar,
Generator or inverter system). In this case ensure that all computer hardware
are connected to unlimited power supply
Scenario 2 (Plan B): Use DR Resources
Recovery: Should the alternative power sources not be available, use the
resources at DR site and redirect traffic to the DR servers
Scenario 3 (Plan C): Acquire New Hardware and rebuild System
Recovery: If it is not possible to use alternative power or use DR resources,
advise users to work in offline mode until normal service has been restored.
Threats
Force Majeure
Application / OS Failure
Links and Network Failure
Hardware Failure
Data Corruption and

Database Failure
Impact
Plan A
1. Primary DC unavailable
2. Critical people at PS
unavailable
Use DR Resources
Apps Unavailability at PDC

(Denial of Service)
Switch to Backup Server
Offsite branches cant

access real-time data
or process transactions
Primary data server

unavailable
Loss of Data and Loss of Data

integrity
Plan B
Rebuild Applications and

recover from Backup
Switch to Back up
Server at DR Site
1. PDC unavailable
2. DR Site unavailable
Use offline Mode
Use DR Resources
Repair/ Replace
Faulty Hardware
Acquire New Hardware

and rebuild System
Use DR Resources
Reconfigure Database
from Manual Data
Use Alternative Power

Figure 23 : Contingency Planning Scenarios
Rebuild Server at
Primary Site
Use Alternative Links
Restore from External

backup media
Power Outages
Plan C
Use DR Resources
Acquire New Hardware
and rebuild System
43.9 Post incident transition

All affected departments must prepare for the orderly transfer of their data files from the DR site
to the primary site. Once a transfer date is set, the Organisation ICT team shall make
preparations to move the backups and any backup files created at the recovery site and store
elsewhere back to the primary facility for use during restoration.
Once the migration is completed, the normal process of moving files to the DR site must resume
as soon as possible.
Once the systems have been restored, communications are functional and processing has been
re-established, the validation process can begin to ensure the system software and
communications are functioning properly
At the close of the restoration activities, Organisation ICT must coordinate, schedule and
conduct a review meeting to:
i.
Validate that all systems are operational
ii.
Identify any items that require any attention
iii.
Summarize and evaluate the disaster response including developing the lessonlearnt document,
iv.
Develop changes to be incorporated into the contingency plan.
v.
Communicate a summary of the test results as appropriate
43.10
Pre declaration of scenario
Perform Staff Evacuation Procedures

In the event of any major incident or notification of a potential disaster like the
sounding of a fire alarm, it is the organizations first priority to ensure the safety and
protection of human life. Hence, all employees would be expected to evacuate the
premises ASAP and gather at the assemble points as identified in the corporate
evacuation plan.
Conduct Preliminary Assessment of IT Infrastructure
The Contingency Plan leader will conduct a prompt preliminary assessment of the
extent of damage if any to the IT infrastructure and check on the availability of and
end user access to critical applications. He may use the assistance of his team at this
stage; however the objective of this preliminary assessment is to ascertain ASAP if
the incident had any impact on the availability of critical applications.
Report to Contingency team leader and give status report
The preliminary assessment result is shared with the Contingency team leader who
uses this information in conjunction with facts on the overall health of the organization
and its infrastructure to make a decision whether a disaster should be declared. If the
situation does not warrant any need to declare a disaster all staff would be asked to
report back to work.

Disaster declared
If the situation demands that a disaster be declared, the Contingency team leader will
formally and officially declare the organization is in a disaster situation. This
declaration will initiate the recovery process and activate the Contingency Plan. At
this stage the Contingency team Leader focuses his attention on managing the BC
teams whereas the Contingency Plan team leader takes over complete charge of the
situation on the Contingency Plan front and manages his teams.
Return to work
If a disaster is not declared, please return to your desks and check whether
everything is in position and normal. In such a situation, there is always a higher
likelihood of the event recurring/other related events occurring. Please keep an
attentive look out for any unusual circumstances.
Please confirm that there are no missing papers, etc., and continue working as usual.
Obtain copy of latest Contingency Planning document
Now that a disaster has been declared, the Contingency Plan team leader must
obtain the latest, updated and authorized copy of the Contingency Planning
document. One latest copy of the DR plan should always be maintained at the
Alternate site; this provision helps ensure that the latest copy is always obtainable
and accessible in the event the primary site is no longer accessible. The Contingency
Planning document is used as a guide to assist the Contingency Planning team
leader to manage and accomplish prompt and systematic recovery of critical systems.
Confirm availability of all team members
The Contingency Planning document is used to ensure that all team members and
the required leaders of DR teams are available for the recovery process. If some team
members are absent (due to leave, sickness or the impact of disaster) the
Contingency Planning team leader authorizes the backup team member to take
leadership and be responsible for that teams activities.
Assemble team to initiate recovery activities
Based on the situation, severity and time of disaster the Contingency Planning team
leader calls for an assembly of all the DR teams to initiate recovery activities and
restore services as per the DR plan.
Evaluate Availability
The team will assess and communicate to Contingency Plan Team leader about the
availability of software in order to restore the critical applications.
i.
Inform Backup Recovery team to evaluate availability

The Backup Recovery team is asked to conduct a detailed assessment of the
backup tapes and its availability at the onsite and offsite storage and provide a
status report on the same.
ii.
Inform End User Support team to evaluate availability

The End User Support is asked to conduct a detailed assessment of the
damage to end user hardware, software and network infrastructure and
provide a status report on the same.
iii.
Inform Hardware team to evaluate availability

The Hardware team is asked to conduct a detailed assessment of the
hardware and to confirm on its availability and access.
iv.
Inform Software team to evaluate availability

The Software team is asked to conduct a detailed assessment of the software
and to confirm on its availability and access.
v.
Inform Network & Communications team to evaluate availability

The Network & Communications team is asked to conduct a detailed
assessment of the network in terms of the core network connectivity, local
area network and data and voice communications and to confirm on their
availability and access.
vi.
Inform Data Center Operators team to evaluate availability

The Data Center Operators team is asked to conduct a detailed assessment of
the physical, environmental and monitoring controls of the data center and to
confirm on the availability and compliance of such controls.
Table 1:Data Center Operation checklist
Description
Facility
Part
Facility
IT
Part IT
Business as
usual
Primary facility
unavailable
Part primary
facility
unavailable
Primary data
center
unavailable
People
Recovery Strategy
N/A
Use alternate
facility with primary
IT and people
Use primary site

and part of
alternate facility
Use primary site

and alternate IT
data center
Part primary
data center
unavailable
Critical people
at primary site
unavailable
Primary facility
and primary IT
unavailable
All resources at
primary site
unavailable
vii.
Use primary site

and part of
alternate IT
Use backup people

from alternate site
Use primary people

at alternate facility
Invoke country
level disaster plan
Inform Contingency Team leader of decision

The Contingency Planning team leader makes his decision based on the
assessment reports and the Scenario Declaration Matrix and informs the
Contingency team leader of his decision
43.11
Post declaration of scenario
Contingency Plan team leader declares scenario

The Contingency Planning team leader declares the scenario by announcing formally
and officially to his team the scenario they must adopt for recovery. This scenario will
dictate the path the team follows and the recovery activities they must undertake.
Test Application Integrity
i.
The contingency team will test the application integrity for all the applications. As
the servers at the alternate location may be replicated on a real time basis with or
without time delay there is a possibility that the application integrity may have been
compromised and the data available on systems may not be up to date or reliable
(e.g. in instances where the primary system data has been compromised due to a
hacking attack or virus outbreak).
ii.
If the application does not load properly or there are a number of instances of illegal
operations and unforeseen aborts, the contingency team will need to recover the
application from the last know reliable backups of the production systems taken
from the primary site.
iii.
The team will have to determine whether the last transaction passed through the
application servers at the main location has been replicated at the servers at the
alternative processing site. The contingency team will need to recover application
data from backups if necessary.

iv.
Prior to the commencement of the software recovery process from backup tapes,
the Software Team Leader will intimate the Contingency Plan Team Leader of the
failure / issue faced in the recovery process.
Use of backup tapes

The following step should be used if backup tapes are required in the recovery
process:
v.
Inform Backup restoration team

The Software Team Leader will inform the Back-up Team Leader of the need
for the recovery tapes for the application / data to be restored.
vi.
Obtain relevant backup media

The Software Team will liaise with the backup team to retrieve the required
backup tapes.
vii.
Restore backups
The backup team will restore the relevant back-ups from tapes based on
requirements defined by the contingency team.
viii.
Retest application/database
Once the back-ups are restored, the Software Team will re-test the relevant
application to ensure that the data is up to date and system is performing as
expected
Once the restoration process has been completed, the backup team will return
the back-up media to the archives and schedule periodic backups from the
production systems at the alternate site
ix.
Inform Contingency Plan Team Leader of failure

If the back-up recovery process is not successful, the Software Team Leader
will inform the Contingency Plan Team Leader.
Test Data integrity

x.
Once the application integrity is established, it will be the responsibility of the

contingency team to test the integrity of the data.
xi.
There can be a requirement to restore applications and or data from backup tapes.
The data will be restored only on a need basis during the recovery process.
xii.
One of the responsibilities for the data integrity test is to identify if there are any
inconsistencies in the various databases in use.
xiii.
If the data integrity has been compromised, the Software Team will be responsible
for liaising with the backup team to obtain the required back-up media and restoring
the data.
xiv.
If any backup tapes are not usable, the software contingency team leader will revert
to the latest working backup and also inform the Contingency Plan team Leader of
the number of days of data loss due to the failure of the restore process.
Confirm availability to Contingency Plan team Leader

Once the data integrity has been established, the Software Team Leader will inform
the Contingency Plan Team Leader of the completion of the recovery process.
Restore data as requested by contingency team
Software team will communicate to backup contingency team the data and location
where the backup needs to be restored. Backup contingency team will obtain required
tapes and will restore the data.
Confirm data recovery to contingency team
Once required data is restored backup contingency team will inform contingency team
so that contingency team can proceed with recovery of services.
Schedule periodic backups for production systems
As alternate site is now hosting critical applications, it is necessary that regular
backup of data is taken. It is responsibility of backup contingency team that backups
of systems available at alternate site are scheduled as per requirement of
contingency team.
Confirm task completion to Contingency Plan team leader
Backup contingency team will confirm the task completion to Contingency Plan team
leader.
Document final incident report stating the root cause and what steps were taken to
fully restore the system back to normal.
44 Organisation/ICT/02/01/Annex 2- Software Business Case

Validation
44.1 Description
Business case validation ensures that a feasibility study is performed to justify the acquisition or
development of new software.
It is critical to emphasize that the use of information technology equipment and software within
Organisation is for business purposes. Much as it is understood that employees may use IT for
personal reasons, employees should bear in mind that this usage should not conflict with the
primary purpose (Organisation business use). In all instances, Organisation expects all
personnel will adopt a responsible and professional approach.
44.2 Objective
All software that is procured, and/or developed in-house must have an approved
case to support the cost and time for development and outsourcing of the software.
business
44.3 Scope
The Guideline shall cover the following areas;
Proposal for changes to existing software
Acquisition of new software
Development of new software

All proposed software into the Organisation IT environment should have a supported business
case and such a business case should be approved by the user department head and the ICT
Department.
No pirated software, i.e. computer software which one possesses illegally, is permitted to be
used either on Organisation's computer or on Personal computers for Organisations business.
Only authorised software covered by specific authorized Organisation license agreements or
authorized shareware /freeware (software freely distributed by software developer) should be in
your possession.
Pirated software not only places the Organisation but also the individual in an illegal position
and also introduces a greater risk of viruses being introduced into our authorised applications
and data. Under Copyright law, the use of illegal copies of software can expose the
Organisation to substantial fines and possible claims for civil damages.
44.5 Responsibility
Roles
User department
User Department head
ICT Department
Responsibilities
1. Generate business case for Software
1. Approve software business case
2. Commit resources for the project
1.Assist in reviewing and approving
software business case
A feasibility study shall be conducted for proposed changes to the current software(s) or
acquisition of new software(s).
Such a study shall be jointly carried out with the business unit or department requesting the
software, the software development team and the Quality Assurance
The business case shall include the purpose of the software, the expected benefit as a result of
the software.
The expected benefit should be qualitative and quantitative in nature.
A business case shall be the end result and shall be escalated to the ICT Department and the
Head of the user department for approval. A business case shall be completed.
The business case form shall include;
ii. Purpose of software
iii.
Benefit
iv.
Scope of the system
v.
Whether it is not covered in another systems
vi.
High level functionality
44.6 Reference
Ref
Document name
ISO 27001 and ISO 27002 Standards
Information Technology Infrastructure Library (ITIL
Control Objectives for Information and Related Technology (COBIT)
44.7 Flow Chart
START
1.
Request for new
functionality
2.
Is it for existing
software application
NO
3.
Document the
Problem or Need
Statement
YES
9.
Prepare a
functionality
decline report
4
Develop Change
request
5.
Analyse High level
requirements
7.
Proceed with
the project?
6.
Carry out
feasibility Study
NO
R.1
8.
Commence
Project Planning
process
YES
R.2
Figure 24: Software Business Case Validation flowchart

Guideline Name
Organisation/ICT/02/01/Annex 3 - Software
Requirements Definition
Organisation/ICT/02/01/33 ICT Project
Planning

R.1
R.2
R.3
45 Organisation/ICT/02/01/Annex 3 - Software Requirements

Definition
45.1 Description
Business requirements for system development should include specifications for functionality,
and process changes or enhancements. These specifications should address both automated
process and manual processes to be implemented.
45.2 Objective
Software requirements definition aims to provide guidance for defining functional and technical
related business requirements for new systems and/or enhancements to existing systems.
These business requirements should specify and define the expected automated processes
45.3 Scope
This applies to all software that is used by East Africa Public Health Laboratory Network Project
supported organisations.

the evaluation. The functional requirements of a system should:
i. Document the process of the process flow for the automated process
ii.
Should specify the competencies and roles that are required to complete the
process.
iii.
Specify the key performance indicators required for the process to be completed
iv.
Specify the key inputs and expect outputs for each process
45.5 Responsibility
Department
Software Development team
User Department
Role(s)
Develop software requirement based on
the user requirement
Develop users requirement against
detailed terms of reference
45.6 Procedure
The development of the user requirements shall be jointly developed with the User department
and the software department
A scope for the requirements shall be outlined and signed by the user department and the
section head of the software department.
The programmer shall develop software requirements specifications (what the software can do)
and present it to the analyst who presents it to the users to seek consent and approval (if the
software meets the needs of the users).
Using unified modelling language UML the requirements shall be documented by the analyst
programmer
The requirements shall be include functional and technical aspects
Once completed they shall be reviewed and signed-off by the user department head and the
software section head and the ICT Department
45.7 Flow Chart
Figure 25: Software requirements Definition Flowchart

Guideline Name
Error! Not a valid result for table.

R.1
R.2
Security Requirements Definition

Organisation/ICT/02/01/Annex 5 - Solution
Design
R.3
46 Organisation/ICT/02/01/Annex 4 - Software Security

46.1 Description
Software Security requirement refers to security aspects that shall be referred to in designing of
the software. Security requirements shall assist in ensuring the safe and secure software
applications shall be introduced in the Organisation operating environment
46.2 Objective
To provide guidance for defining security related business requirements for new systems or
enhancements to existing systems. These business requirements should specify and define the
type and method of controls (automated and manual) to be incorporated into the systems, along
with the scenarios of their expected use
To ensure that security is an integral part of information systems; Information systems include
operating systems, infrastructure, business applications, off-the-shelf products, services,
and user-developed applications. The design and implementation of the information system
supporting the business process can be crucial for security. Security requirements should be
identified and agreed prior to the development and/or implementation of information
systems.
To ensure that all security requirements are identified at the requirements phase of a project
and justified, agreed, and documented as part of the overall business case for an information
system.
46.3 Scope
A minimum list of issues to be addressed by security requirements follows:
i.
Access controls (mandatory or discretionary)
ii.
Administrator controls
iii.
Data classifications
iv.
Data encryption
v.
Data output access
vi.
Data storage recovery
vii.
Data storage reliability
viii.
Network security
ix.
Operating system configuration
x.
Physical security of system devices
xi.
System level access
xii.
System- to- System identification
xiii.
User access methods
xiv.
User account configuration
xv.
User identification

Business requirements for system development should include specifications for security
controls.
These specifications should address both automated controls and manual controls to be
implemented.
the evaluation. The security-related requirements of a system should:
i.
Reflect the sensitivity of the types of information to be handled by the system
ii.
Include a risk analysis that documents the types of risk associated with the
system
iii.
Consider all pertinent data security standards that may affect security
requirements (e.g.., Law Enforcement and other applicable compliance
requirements)
46.5 Responsibility
Department
Software Development team
User Department
Role(s)
1. Develop software requirement based
on the user requirements
1. Develop users requirement
2. Develop security features of the user
requirements
46.6 Procedure
All application and infrastructure developments must undertake security design and coding or
build activities in such a way as to implement the specified security requirements in an effective
and
complete
manner.
The
procedure
is
as
follows;
i.
The design of the security mechanisms must be formally documented.
ii.
The design of the security mechanisms must be subject to a formal independent

review and sign-off by Organisation Information Security personnel
iii.
The security mechanisms being implemented to satisfy the Guideline-driven

requirements must be identified in the security design specification and must at
least provide for and enforce security Guideline on: user/device authentication;
control of sensitive function; segregation of sensitive/critical data; protection of
system resources, devices, etc.; logging of attempted breaches of security
mechanisms; backup of information; and resilience and disaster recovery.
iv.
The security design must adhere to the secure design principle of simplicity: the
more complex a design, the less secure is the system; however, the use of
complex protocols (e.g. networks) and sophisticated coding techniques (e.g.
cryptography) has a positive role in ensuring security.
v.
The security design must adhere to the secure design principle of appropriate and
balanced security: security functionality must be appropriate to the scale of threat
and risks and balanced against the cost in terms of development and limitations
on design.
vi.
The security design must adhere to the secure design principle of least privilege:
all processes and users within a system should be given just sufficient access to
information and resources as the functionality requires.
vii.
The security design must adhere to the secure design principle of overt design:
security mechanisms should be overt and positive, rather than rely on obscurity of
coding, function or protocols. Only in specific circumstances should complexity
and obscurity be relied upon, based on guidance from Organisation Information
Security.
viii.
The security design must adhere to the secure design principle of design for a
hostile environment: security mechanisms must be resilient to attacks or
unpredicted changes in other parts of a system.
ix.
The security design must adhere to the secure design principle of defence in
depth: each basic threat to security of the design should be countered by at least
two applicable mechanisms.
x.
The security design must adhere to the secure design principle of default to
denial: security mechanisms should default to not granting access to information
or resources, rather than attempt to successively remove all undesirable access.
xi.
The security design must adhere to the secure design principle of maintaining
integrity of security: as far as possible, security mechanisms should be selfdefending, i.e. any tampering with basic mechanisms or data should be signalled.
xii.
The security design must adhere to the secure design principle of security
auditing: security mechanisms must provide a complete record of relevant events
and alarms of attempted breaches; also mechanisms to allow regular inspection
of events.
xiii.
The security design must adhere to the secure design principle of secure lookand-feel: security mechanisms should provide obvious warnings and indicators of
their presence, without any loss of secrecy of their method of working.
xiv.
The security design must adhere to the secure design principle of automated
installation of security: as far as possible, the installation of a secure environment
and initiation of security mechanisms should be automated (e.g. scripted server
builds).
xv.
The security design must adhere to the secure design principle of secure
maintenance: maintenance of the software and hardware environment during
operational life should never require the dismantling of any security mechanism.
(However, temporary disabling may be acceptable, under strict control.)
xvi.
Security aspects of the design must be tested during early stages of development
through design reviews, unit test and system test; security functionality must be
subject to rigorous testing at integration and acceptance testing stages of
development.
xvii.
Where an application is being developed to operate in a client/server environment

and the controls on the server are not sufficient, then the client must be protected.
xviii.
The design of an application or infrastructure under development must address

the requirement for resilience to single component (hardware and/or software)
failure, using, for example, dual redundancy, in line with the security requirements
and the formal risk analysis.
xix.
The design and operation of any user interfaces into specific security functions
provided by an application or infrastructure must take into account ease-of-use by
the target user-base.
xx.
The design of the user authentication and user input mechanisms for an
application or infrastructure must take into account the general physical
environment in which the typical user will operate with the system, and suitable
enhancements to the security of the interface included.
xxi.
The design of an application or infrastructure under development must not only

always provide for a suitable level of logging of security-relevant events (at a level
determined by the risk-driven security requirements), but must also provide for the
security of the application or infrastructure logs written, using access permissions,
integrity checks, encryption, etc.
xxii.
The design of the audit trail or logging functionality of an application or

infrastructure under development must ensure that the security of any
CONFIDENTIAL or SENSITIVE information, including security-related information
(e.g. passwords) is compromised as a result.
xxiii.
The design of each application must include allowance for the use of computerassisted audit and logging tools in order to capture an appropriate variety of both
application and system data during monitoring and investigations.
Application Baseline Controls;

i.
All application operating environments must have all unnecessary system,
network and utility software removed prior to production operation.
ii.
Where the operating system and network or other infrastructure components

that will support an application in production provide key security mechanisms,
these should be used to satisfy the security requirements of the application in
preference to bespoke application controls, so long as the application code can
be tightly bound to the operating system; i.e. it is not possible for application
users to access the operating system directly. If this degree of control is not
feasible, the appropriate controls must be implemented at both the operating
system and application level.
iii.
Application source code, object code, code editors, code generators and
language compilers must not be stored on any production system, except where
the application code is run-time compiled or interpreted; in this case, the
application design must include specific controls to ensure the security of this
code.
iv.
All user application sessions and processes must be terminated when the
application is shut down so that no direct operating system or any other form of
unauthorised access becomes available to the user.
v.
Externally facing application 'announcement' messages displayed to users on

screen prior to login must not indicate Organisation's name, business process
or supporting IT platform that the application facilitates (except by deduction by
the well-informed, authorised user).
vi.
Each application must provide robust mechanisms that ensure that every user's
logon session is captive to the designed application environment and
functionality and cannot give unrestricted access to the operating system level.
vii.
Each application must provide robust mechanisms that ensure that every user's
logon session restricts access to the application and to authorised application
functions only.
viii.
There must be no means of obtaining any additional unauthorised application

functionality through the use of alternative means of access to the application,
e.g. via report writing options, query options, batch processing, command line
access, ODBC database links, shell escapes etc.
ix.
The file access permissions established for application executables and

command scripts must restrict access to the minimum population of authorised
user accounts on the platform supporting the application.
x.
The use of privileged embedded passwords or keys in application scripts and

code is strictly prohibited unless authorised by Organisation Information
Security, normally by means of a Risk Acceptance or Guideline Dispensation.
xi.
Where an application emulates or replaces another pre-existing procedural,

physical or logical component or function, then the security controls that applied
to the original component or function must also be applied to the application
Database Management System Baseline Controls;

i.
Certain basic and generic controls over database management system
functionality
must be implemented, as appropriate, during development of
applications using a database.
ii.
For any application employing a Database Management System (DBMS), the

security controls and views defined within the DBMS must correspond to the
security requirements and controls provided by the application, including the
access rights and privileges applied to user profiles.
iii.
Database Management System (DBMS) managed information used within any

application must only be accessible via the application and its interfaces, not via
direct user sessions within the DBMS.
iv.
Multiple applications that are run on a common database server must have the
same level of security requirements.
v.
Restoration of application integrity must be possible through rollback or other

means.
vi.
For any application employing a Database Management System, the database

design and facilities must include the capability to roll back to a fixed point in
time and recover data up to that point.
Application Data Integrity Baseline Controls;

i. Certain basic and generic controls over the manner in which applications are
designed to handle the integrity of information must be implemented, as
appropriate, during development and in production use. Certain basic and generic
controls over the manner in which applications are designed to handle the integrity
of information must be implemented, as appropriate, during development and in
production use.
ii.
Each application must include controls to ensure that input transactions are
processed only once.
iii.
All applications must provide for the validation of input data against pre-defined
parameters representing valid ranges, etc.
iv.
The application must provide facilities to enable changes to the data input
validation parameters to be made without any application code or configuration
changes.
v.
Modifications to critical static data and configuration data must only be allowed by
certain privileged application accounts that should be allocated to specific staff
(business line or support) as appropriate.
vi.
Changes to pre-defined input validation parameters in any application must be

logged and reviewed by management in charge of the principal business unit using
the application.
vii.
All input validity and authorisation checks provided by an application must be

performed at the point of entry of the information or instruction.
viii.
Where an application involves batch input or batch interfaces with other

applications, reconciliation totals must be provided and checked at each stage of
input processing.
ix.
The access rights and permissions applied to application data files must protect
against unauthorised modification, patching or overwriting of the flies.
x.
The business owner(s) of each application or their delegate(s) must review

business transaction entry reports on a regular basis.
xi.
During testing, development staff must check that the application actually does
what it was designed to do and that the output is complete and accurate.
xii.
All application output must be protected against unauthorised creation,

modification, deletion, replacement or replication when both in spooled output form
and as output
xiii.
The integrity and completeness of printed output from an application must be able
to be validated using report numbering, end of report messages, nil reports (where
nothing explicit is reported) and periodic report acknowledgements (i.e. every 6
months check the user is receiving reports and that they are still needed).
xiv.
Each application or its associated business process must provide for checks during
input to ensure that data entered complies with, and is not contradictory to, any
static data for that application.
xv.
Common static data must be shared and maintained across as many applications
as possible that require the same data.

xvi.
All static data used by an application must be periodically reviewed for

completeness and accuracy by the business owner(s) of the application(s) or their
delegate(s).
Web Application Baseline Controls;

i.
Where applications are being developed to offer customer services or products

over the Internet ("Web applications" as opposed to public Web sites), the design
and build must take particular account of specific constraints and rules regarding
the application, business and infrastructure environments.
ii.
Web applications must be based on the Organisation standard web server

platform that has been secured in line with the published Organisation standard for
secure configuration of the web server and underlying operating system; no web
server or operating system functionality that is not specifically allowed within those
standards can be assumed to be available during system design or build.
iii.
Web applications must be based on the Organisation standard web server platform
that will be situated in Organisation standard firewall complex for customer-facing
applications; the design and build must take into account all constraints that this
will impose.
iv.
The IP protocols, ports and services that the Web application is designed to make
use of must be specified and approval of Organisation Information Security sought
prior to the completion of the design stage of the development.
v.
All Web sessions between remote users and web servers over the Internet that
involve the transfer of customer-specific information and/or business transactions
must be protected for confidentiality and integrity by use of cryptographic tunnelling
initiated via cryptographic certificate authentication; where the IP Web protocol
(http) is being used, this requires the use of Secure Sockets Layer (SSL) protocol.
vi.
Where the SSL protocol is being used to protect applications that are being
developed to offer customer services or products over the Internet ("Web
applications"), the encryption tunnel must be based on at least 128-bit length
encryption keys.
vii.
Where Web applications are being developed, the design of the authentication of
remote users connecting via a browser session must provide, as a minimum level
of security, authentication by secret password followed by initiation of
cryptographic tunnels using key exchange protected under server-side certificates;
security requirements must be reviewed with a view to increasing the
authentication strength as appropriate from this minimum.
viii.
ix.
Where Web applications are being developed, the design of the information flows
into and out of the web server to support the application must comply with certain
basic rules:
a. the web server must not act as pass-thru for information flowing from the
Internet directly to any host or destination on the internal network;
b. updates of information resident on the web server from internal systems must
be initiated by the internal systems;
c. updates of information from users or nonOrganisation hosts on the Internet to
the web server are allowed (and must be subsequently subject to
authentication and validation checks on the web server);
d. Updates of information from the web server to internal systems must not be
initiated by the web server, but must be initiated by the internal systems. No
other information flows are allowed without specific Guideline Dispensation.
Where Web applications are being developed, the design of the application code
must minimise the number and complexity of interfaces between the web server(s)
and internal systems.
x.
Where Web applications are being developed, the design of the application code
resident on the web server must not require the code to operate with high
operating system privileges in normal operation; the minimum sustainable level of
privilege must always be designed.
xi.
Where Web applications are being developed, specific code reviews must be
undertaken of any scripted or run-time executed code of any type of class; all such
code must be located in non-public and suitably protected directories within the
web server.
xii.
Where Web applications are being developed, specific checks must be made
during development to ensure that all rendered web content (HTML and XML
content) is valid and is rendered correctly and that all hyperlinks embedded in the
content are valid and functional.
xiii.
Where Web applications are being developed, the design must provide specific
controls that ensure that the integrity of any SENSITIVE information that is resident
on the web server (e.g. price information) is maintained and confirmed regularly.
xiv.
Where Web applications are being developed, the design of each application must
not rely upon the security of any other web application server co-located in the
firewall complex and must not present vulnerabilities itself that could compromise
the security of other web application servers.
xv.
Where Web applications are being developed, the design of each application must
ensure that any web server, operating system and security mechanism
configuration information is not exposed through the html and web publishing
functionality of the server.
xvi. All Web applications must be subject to independent Security Functionality

Acceptance Testing, involving probing of specified and unspecified functions

(sometime called "Penetration Testing"); testing must be independent of the project
team and may involve external parties.
xvii.
Where Web applications are being developed, the application development plan
must take into account the requirement under Group Information Security
Guideline and potentially under specific local statute and regulation that the web
server code and infrastructure must be subject to independent Security
Functionality
Acceptance Testing, involving probing of specified and unspecified functions (sometime called
"Penetration Testing").
i. Where Web applications are being developed, a written signed contract or a
published set of standards terms and conditions of business must exist to govern
the provision of services or products.
ii.
Where Web applications are being developed, the business process and liabilities,
privacy Guideline and customer statement regarding information and system
security Guideline must be codified within the contract written to govern the
provision of the service or products.
iii.
Where Web applications are being developed, the contract written to govern the
provision of the service or products must specify the responsibilities and actions
expected of the customer for maintaining the security of information.
iv.
Where Web applications are being developed, the business process, contractual
terms of business, published privacy Guideline and customer statement regarding
information and system security Guideline must be reviewed and agreed by Group
Information Security, Group Legal & Compliance, and where appropriate, by
external expert legal and regulatory advisors.
v.
Where Web applications are being developed, any limitations on the markets, valid
geographical territory, business sectors for which the services or products are
being offered must be determined and suitable wording provided on the service or
product home page to make these limitation on scope absolutely clear to the
connecting user.
vi.
Where Web applications are being developed and the scope of the service is
global, then the aggregate of the local statutory and regulatory requirements of the
Group's principal markets regarding business practice and information and
systems security must all be fulfilled.
vii.
Where Web applications are being developed and the scope of the product and
service is limited to various local markets, all local statutory and regulatory
requirements regarding business practice and information and systems security
must be fulfilled.
viii.
Where Web applications are being developed, the contract written to govern the
provision of the service or products must specify the process for the registration,
validation and authorisation of new customer-users of the application; specific
mechanisms for validation of customer-user identity and access rights must be
devised and documented.
ix.
Where Web applications are being developed, the Web home page to which users
connecting via remote browser sessions are directed must include, directly or via a
highly visible hyperlink, a clear understandable statement of the Group's Guideline
regarding the privacy and security of information provided to it via such Internetbased applications; such statement must have been approved by Group Legal &
Compliance and Group Information Security.
x.
Where Web applications are being developed and the application makes use of a
third-party service component (e.g. information feed), a contract must exist that
addresses responsibilities and liabilities for the security of information received and
as processed on the web server.
Use of Standard Technology Components & Products;

i. The design and build of applications and infrastructures under development must
make use, wherever possible, of technology components and/or products that
have been identified and published as standards by Organisation Technology.
ii.
When an application or infrastructure component is under development, reference

must be made during the design stage, to the published Information Security
Architecture Framework and the Organisation Technology standard components
and products list for the selection of suitable technology.
iii.
A Standards Dispensation must be obtained by the development project manager

in charge of a new application or infrastructure development by application to the
Technology Architecture & Standards Committee for the use of any technology that
is not included in the Organisation Technology standard components and products
list.
iv.
Where a Standards Dispensation has been requested for a new application or

infrastructure development to enable the use of any technology that is not included
in the Organisation Technology standard components and products list, suitable
review and testing of the non-standard technology, focusing particularly on the
security impact, must be performed and documented before the Dispensation is
granted.
Planning;
i.
Plans for the development of applications and infrastructure must explicitly include
work activities and milestones for the relevant information security tasks and
deliverables.
ii. Guidance must be sought from Organisation Information Security regarding the
information security work activities, milestones and deliverables to include in the

project plan for an application or infrastructure development.
iii.
The project plan for an application or infrastructure development must include the
activity required to produce at least the following specific security deliverables:
security requirements document derived from a formal risk analysis, security
design document, security test plan and specifications, risk acceptance document
(if relevant), Guideline Dispensation requests (if relevant).
iv.
The project plan for an application or infrastructure development must include at

least the following specific security milestones: security requirements sign-off by
business owner and Organisation Information Security, security design sign-off by
Organisation Security Engineering, security testing sign-off by Organisation
Information Security, final project risk signoff by business owner and Organisation
Information Security.
v.
All resources and costs required for the production of security deliverables during
an application or infrastructure development are the responsibility of the
development project manager and the business owner and estimates must be
included in all project cost projections.
User & Administrator Training

i. All application and infrastructure developments must produce suitable training
materials and capacity to ensure effective use of all security mechanisms requiring
user or administrator interaction.
ii.
User guides must be documented for each application and infrastructure

development that include any specific instruction to users regarding system logon
and obtaining access rights.
iii.
Administration guides must be documented for each application and infrastructure

development that include specific instructions to system and security
administrators regarding the use and control of security access features, access
rights, security logging, etc.
iv.
Where appropriate, user or administrator training sessions must be provided to

instruct users and administrators in specific security features; such sessions must
be planned and prepared as part of the development deliverables.
Active Mobile Code;

i. To ensure that the use of active mobile code does not present a threat to
Organisation or its customers' networks.
ii.
The use of active mobile code whether within the Organisation's development or
operating environments, or where downloaded by staff presents a real threat to
Organisation, therefore where appropriate, Organisation will filter for active mobile
code
iii.
On a proprietary system, where a business requirement dictates the use of active

mobile code, a risk acceptance must be undertaken to determine the level of risk
imposed by its use both to Organisation and to Organisation customers.
iv.
Where active mobile code is used on Organisation proprietary or operated systems

it must be digitally signed by a trusted source to show who wrote the code and that
it was written in a way that its use will not be detrimental to Organisation or its
customers.
46.7 Flow Chart
Figure 26: Software Security Requirements Definition flow chart

Guideline Name
Reference Flow Chat

R.1
47 Organisation/ICT/02/01/Annex 5 - Solution Design

47.1 Description
Solution design ensures that software that is designed in-house within Organisation follow a
systematic approach to ensure easy maintenance and quality in the solution.
This standard is intended for use in design situations in which an explicit software design
description is to be prepared. These situations include traditional software construction
activities, when design leads to code, and reverse engineering situations where a design
description is to be recovered from an existing implementation.
The standard can be applied to commercial and scientific software that runs on digital
computers. Applicability is not restricted by the size, complexity, or criticality of the software.
This standard can be applied to the description of high-level and detailed designs. This standard
is not limited to use with specific methodologies for design, configuration management, or
quality assurance. This standard does not require the use of any particular design languages,
but establishes requirements on the selection of design languages for use in a software design
description (SDD). The standard can be applied to the preparation of SDDs captured as paper
documents, automated databases, software development tools or other media.
47.2 Objective
To provide a guideline for the solution design for new systems or enhancements to existing
systems
To provide a guideline for information content and metadata organisation of software design
description
To provide guidance on the selection of design languages to be used for software design
description and requirements for documenting design viewpoints to be used in organizing a
software design description.
47.3 Scope
The software designed Guideline shall apply to internally developed software as well as
outsourced software from the vendors.
Software design shall considered be for upgrading existing software and the designing of new
software.

The systems development life cycle methodology to be used should be an approved approach
for all in-house developed applications. Variation from these standards requires prior written
permission from the ICT Department. Organisation needs to agree on standard methodology to
be used.
The Organisation software development team must be trained in the usage of software design
techniques such as Unified Modelling Language before any design process
Solution design shall start after completion of signed user requirements which shall include
technical requirements, functional requirements and security requirements
47.5 Responsibility
Roles
Software Development
User Department
Responsibilities
1.Design software based on approved
software requirement and user
requirements
2. Seek user approval of the software
design
1.Participate in software design process
2 Approve software design
47.6 Procedure
In house developed Software
i. The following are the procedures that shall be used in the development of in-house
software.
ii.
iii.
iv.
A software design plan shall be developed prior to the design process and such a
plan shall include;
a. Key design activities
b. Software design team
c. Tool and methods to be employed
d. Project and design methodology
The Organisation software development team shall identify appropriate software
design tools and standards that will be used in the documentation of the software
design and such tools will be approved by the Software section head and the head
of the particular software project.
The software design process will be based on the approved and signed user
requirement and such requirements will include the technical, functional and
security requirements.
v.
A software design team shall be selected and approved by the Organisation

Software section head the team will be appraised on all aspects related to the
project.
vi.
All software design standards shall be in accordance with approved software

development methodology
vii.
Organisation software development team must have a quality assurance process

in place that meets accepted UAT standards.
viii.
Once design standards are developed and documented they shall be approved by
the head of the software section and the ICT Department
Outsourced software
i. This procedure shall apply to external software vendor responsible for off the shell
package software. This procedure shall apply to all selected software vendors be
Organisation.
ii.
Software vendor shall avail and train Organisation Software department team on
their software design and the standards they employ.
iii.
The software design process will be based on the approved and signed user
requirements and such requirements will include the technical, functional and
security requirements.
iv.
Vendor will make effort to train Organisation on the development lifecycle that will
be employed in the project
v.
Once design standards are developed and documented they shall be approved by
the head of the software section and the ICT Department and the vendor project
director and managers.
47.7 Flow Chart
Figure 27: Solution design flowchart

Guideline Name
Organisation/ICT/02/01/Annex 6 - Development &
Customisation

R.1
R.2
48 Organisation/ICT/02/01/Annex 6 - Development &

Customisation
48.1 Description
Software development and customisation is a process for translation of the specifications design
and requirements into source code and this will be in the form of customisation or development.
This process is can either be an internal where the software is designed in-house within
Organisation or external process where is may be developed by a software vendor.
48.2 Objective
To provide a guideline for the customisation or development of new or existing software
applications in compliance with the software design standards.
To ensure that the programming source code follows a consistent standard that is readable and
maintainable.
To enable system developers and administrators to implement consistent and simpletouse
security standardising software development projects
48.3 Scope
This Guideline shall apply to internally developed software and shall be used to review external
or outsourced development of software as well as customisation of software packaged by
external vendors.

Only trained and experienced programmers shall be allowed to develop or customise internally
developed software.
Regarding outsourced software Organisation shall ensure that competent and approved
development and customisation team shall work in the project.
The systems development life cycle methodology to be used should be an approved approach
for all in-house developed applications. Variation from these standards requires prior written
permission from the ICT Department.
The Organisation software development team must be trained in the usage of software design
techniques such as Unified Modelling Language.
48.5 Responsibility
Roles
Responsibility
1. Customise or develop the software
based on approved designs.
2 Reference the design against approved
software and user requirements
48.6 Procedure
Control over Development Processes;
i. All development activities must be conducted in such a manner so as not to
compromise the security of any information and functionality.
ii.
Development of applications and infrastructure must not be conducted in the

production environment.
iii.
Development environments must be segregated logically from the production

environment using mechanisms such as firewalls and filtering routers.
iv.
Development, test and production environments must be separated and a formal

documented process must be in place to manage the migration of application
code, changes or additions from one environment to another.
v.
Development environments must be subject to basic security controls such as

control over access and change control, albeit at a lower level of rigor than in
production environments.
vi.
Business information may only be used for testing of code under development if
the relevant business owner(s) have given specific permission.
vii.
Where SENSITIVE production information is to be used for testing of code under

development, any customerspecific information must have been removed.
viii.
Development staff must not have ongoing access to production environments,

even for the purposes of support.
ix.
Development staff must not be granted access to production systems for the
purposes of support or emergency fixes unless the access has been authorised by
the business owner or a suitable and authorised delegate.
x.
Development staff must not be granted access to production systems for the
purposes of support or emergency fixes unless the access is timelimited and the
activity of the development staff is subject to monitoring by designated production
IT staff.
xi.
All development environments must implement the full Bank standard AntiVirus
controls; this applies whether the development environment consists of servers,
workstations or both.
xii.
Where Software Engineering or other development tools are employed to

automatically generate code, specific testing and inspection of the code must be
undertaken to verify its integrity and any specific security controls that it
implements.
Change &Version Control during Development;

i. The process of development of software must provide for the proper control over
changes, as well as the control of versions of all deliverables.
ii.
The security deliverables from an application or infrastructure development must

include documentation, source and executable code: including at least formal
security requirements specifications, formal security design specifications, and
coded security functionality, specifications of security testing and documented
proof of security testing.
iii.
The process of development of software must provide for the proper specification,
justification and authorization of changes to requirements, design and code
affecting security functionality.
iv.
Where development of applications or infrastructure is being conducted by

thirdparties, the contract must specify the change control authorization
requirements for changes to security deliverables.
v.
The process of development of software must provide for the accurate

identification and control of access to various changed versions of all deliverables.
vi.
The control over access to versions of development deliverables is the

responsibility of the development project manager; a configuration management
system may be used to provide an effective mechanism for this; where such a
system is used across a number of developments, the responsibility must lie with
the application production support manager for its proper operation.
vii.
Access to controlled versions of development deliverables must be restricted to

authorised developers engaged on the specific development project; authorization
must be provided by the relevant development project manager or application
production support manager.
viii.
The version and change control applied to security deliverables for an application
or infrastructure development must provide for the full recording of the details,
justification, timing and authorization of each change and the versions resulting.
ix.
The version control applied to security deliverables for an application or

infrastructure development must provide for the secure retention of at least the
previous two versions.
x.
Release of changed versions of coded deliverables must occur only after any
security testing required by Bank Information Security has been successfully
completed.
xi.
Release of changed versions of coded deliverables must occur only after the
formal signoff by the developer, justifier and authorizer of the change has been
recorded; these roles must not be held by the same individual.
xii.
All emergency application code, configuration, database or data changes

undertaken under time pressure and before formal change control can be applied
must be retrospectively reviewed and authorised immediately after a successful
resolution to the emergency has been achieved.
xiii.
The vendor must review all code before submitting the application to the
Organisation. Once received by the Organisation, the application will be reviewed
by Organisation to ensure that the relevant standards have been met. These
standards include, but are not limited to, the following Standards, practices,
conventions, and metrics;
a.
b.
c.
d.
e.
f.
g.
Reviews and audits;

Testing;
Problem reporting and corrective action;
Tools, techniques, and methodologies; and
Source Code control.
System Objectives
System Constraints
48.7 Flow Chart
Figure 28 : Development & Customisation flowchart

Guideline Name
Organisation/ICT/02/01/Annex 5 - Solution Design
Organisation/ICT/02/01/Annex 8 - System
Acceptance Testing

R.1
R.2
49 Organisation/ICT/02/01/Annex 7 - Separation of
Development and Operational Facilities
49.1 Description
Operational computing environments should be separated from development, and test
computing environments to reduce the risk of one environment adversely affecting another
49.2 Objective
To require that there is separation of operational, development, and test computing
environments to reduce the risk of unauthorized access or accidental changes to operational
software or data.
49.3 Scope
The scope of this Guideline applies to the Organisation information processing and
communication facilities used for development of software. This Guideline addresses procedure
that defines the separation of Organisation computing environments.

Separation between operational, development, and test systems should be maintained to
reduce the risk of unauthorized changes or access.
To operate properly, each type of computing system requires a known and stable environment
and such an environment should be prepared for operational, development, and test systems
The opportunity for interference among development, testing, and operational systems should
be prevented.
49.5 Responsibility
Roles
Responsibilities
1.Set up software development and
operation environment
2. Test environment
3. Ensure the environment in compliant
with the general software guidelines,
access control and network access
guidelines
4. Address any recommendation from the
Quality assurance team
Quality Assurance
1.confirm correct set up software

development and operation environment
2. report any issue to the Software
development team
49.6 Procedure
The following control procedures should be considered by the Organisation software
development team;
Run development and operational software on different computer processors, in different
domains, or in different directories.
Separate development and testing activities from production activities.
Prevent the access of software development utilities from operational systems, when not
required.
Avoid using the same log-on procedures, passwords, and display menus for both operational
and test systems, to reduce the risk of accidental log-on and other errors.
Implement controls to ensure that administrative passwords for operational systems are closely
monitored and controlled.
Define and document the procedure for transferring software from development to operational
status. Such transfers should require management approval
49.7 Flow Chart
Figure 29: Separation of Development and Operational Facilities flowchart

Guideline Name
Organisation/ICT/02/01/Annex 5 - Solution Design

R.1
50 Organisation/ICT/02/01/Annex 8 - System Acceptance

Testing
50.1 Description
Systems acceptance testing is the process of testing the developed software solution to ensure
that it is working according user requirements.
System acceptance criteria for all new information systems and system upgrades must be
defined, documented, and utilized to minimize risk of system failure.
50.2 Objective
To minimize the risk of system failure due to inadequate testing and validation acceptance of
new or upgraded information systems
To ensure that user accept a system that working in accordance to the specified and outlined
user requirements
50.3 Scope
The scope of system Acceptance testing shall apply to Organisation information processing and
communication facilities; this Guideline addresses the requirement for system acceptance
testing of all new or upgraded Organisation information systems and services.
System acceptance testing shall apply to software that is developed in house and software the
is developed externally by software vendors on behalf of Organisation

Prior to the implementation of new or upgraded information systems, care should be taken to
ensure that all requirements for acceptance have been met.
User Acceptance testing criteria should be clearly defined, documented, and tested, with
consideration given to the following controls:
i.
Manual operating procedures
ii.
Authorized security controls
iii.
Error recovery, restart, and contingency plans and procedures
iv.
Operation training on use of the new system
v.
Penetration testing
vi.
Business continuity preparations
vii.
Projected performance and capacity requirements
viii.
Standardized routine operating procedures
ix.
User verification of proper operational performance
x.
Verification of the non-impact of the new system on existing systems and on
overall organizational security
Test scripts for user acceptance testing shall be developed in line with the user requirements.
50.5 Responsibility
Roles
User Department
Responsibilities
1. Co-test the system with end users.
2. Develop a technical test criteria
3. test technical test criteria
4. Provide pass fail result
5. Address all fail results in-order to get
approval.
1. Develop a test criteria for the system
2. Design and develop test scripts.
3. Test the software
4. Provide pass or fail results to software
development team
5. Approve software once all test have
passed
50.6 Procedure
User acceptance testing is a very critical part of the software development life cycle and the
same criteria for systems acceptance testing shall apply for all system i.e. developed internally
or externally developed by the vendor on behalf of Organisation.
A System Acceptance testing criteria shall be compiled by the user department of the system
and the criteria shall be developed based on the approved user requirements and scope of the
project. The main aim of the testing criteria which shall be in the form of test scripts is to confirm
whether the system is working accordance to requirements.
Once the test criteria is developed through test scripts a pass or failure decision will also be
determined based on the scoring or performance of the system in deferent areas.
Where the systems passes the acceptance testing it shall be handed over to the user
department and where fails it may go back to any of the phases before acceptance testing for
correction.
50.7 Flow Chart
Figure 30: System Acceptance and testing flowchart

Guideline Name
Organisation/ICT/02/01/Annex 6 Development & Customisation

R.2
R.1
51 Organisation/ICT/02/01/Annex 9 - Contingency Planning

51.1 Description
The purpose of this Incident Response Plan (IRP) is to provide a structured method to
managing the incidents that are within Organisation. This will reduce the time spent in
recovering from incidents and will help in minimising the effects of an incident after it has
happened and will help in preventing recurrence.
51.2 Objective
To respond to serious attacks quickly and effectively, reducing any potential business impact
and to reduce the risk of similar incidents occurring.
To ensure that Organisation is able to identify perpetrators of malicious acts and that
Organisation preserves sufficient evidence to prosecute them if required.
51.3 Scope
The scope of incidents is limited to incidents that require the activation of the Computer Incident
Response Team.
This does not cover operational incidents that are managed by the service desk.
The document also does not cover incidents that have been escalated to disaster management

All information security incidents must be recorded reviewed and resolved using an incident
management process.
Information security incident management communications must be limited to those individuals
defined in the communications plan. Details of incidents should only be shared with individuals
with a need to know basis.
Where it is necessary to make changes to systems, applications or networks the
incident response procedure must feed into any existing change management
process.
Incidents must be reviewed to identify common threats and trends.
Access to the information security incident management system must be restricted to authorised
individuals.
Potentially compromised technology must not be used for any element of the
information security incident reporting process.
A process to maintain contacts with relevant authorities to support the information security
incident management process must be documented.
There must be mechanisms in place to enable the number, frequency, types and
impact of information security incidents and issues to be quantified and reviewed.
51.5 Responsibility
Ref
Department
CIRT
Role(s)
The CIRT is comprised of a Team Leader and team members
with various roles and responsibilities.
The Team Leader is responsible for the following:
11. Making the judgement on whether the incident
should be classed as an Incident type I or II.
12. Constituting the appropriate CIRT for the incident
and assigning technical and support (e.g.
research, scribing and welfare) responsibilities.
13. Providing
a central reporting point and
coordinating response efforts.
14. Scheduling periodic status update meetings as
appropriate.
15. Ensuring that the CIRT follow set procedures in
responding to incidents and that documentation
of events is comprehensive.
16. Escalating the incident information to department
management. Providing a contact point for
support departments.
Technical Team members are responsible for the following:
17. Promptly responding to queries and requests
from the Team Leader.
18. Participating
in evaluating and resolving
incidents.
19. Accurately and comprehensively documenting
their actions.
20. Evaluating the incident response.
The Welfare role (optional) is responsible for the following:
4. Ensuring team members have access
to the premises outside regular
working hours if required.
5. Organising safe parking for team
members outside regular working
hours.
6. Provision of refreshments for team
members required to work long hours.
Transport to and from work, if required.
Note: All members of the ICT Department are potential
Technical and Support Team members.
Users
a. Users should immediately report any suspicious activity
that may indicate a security incident is in progress to the
Help Desk administrator. For example virus warnings,
unusual behaviour of the workstation, unreasonable
figures in applications, denial of service etc.

a. IT department managers work with the CIRT leader
to provide the required skills to execute this IRP. In
addition, Managers ensure that their staff know
the
reporting
procedures contained in this
document and are aware of the IT Procedures
manual of the Organisation.
a. System Administrators report any suspicious activity
or actual technical faults on the network
infrastructure (devices, servers etc.) to the CIRT
leader. They may also be called upon by the CIRT
leader to determine and implement a solution.
a. Security Administrators report any suspicious activity
reported by the monitoring tools to the CIRT leader.
They may also be called upon by the CIRT leader to
Support Departments
a. Support
departments
include
Administrative
Services, Human Resources, Security, and Legal
who may be required to participate in resolution of
the incident. ITD management will request them for
support in incidents that require their involvement for
example if the incident is caused by a power failure
or is deliberately caused by a staff member or if
there is likely to be violence. Request will be made
according to the communications plan (Appendix A).
b. When support departments participate in incident
resolution, they will be responsible for accurately and
comprehensively documenting their activities and
submitting the report to the CIRT leader. Activities
will be recorded in the Actions Taken Form
(Appendix B).
Vendors
a. Vendors work with the CIRT team to resolve the
incident.
51.6 Procedure
There are seven roles that constitute the incident management structure. The responsibilities of
each of these roles are detailed below;
51.7 Roles and Responsibilities

xiii.
Computer Incident Response Team (CIRT)

The CIRT is comprised of a Team Leader and team members with various roles and
responsibilities.
7. The Team Leader is responsible for the following:
8. Making the judgement on whether the incident should be classed
as an Incident type I or II.
9. Constituting the appropriate CIRT for the incident and assigning
technical and support (e.g. research, scribing and welfare)
responsibilities.
10. Providing a central reporting point and coordinating response
efforts.
11. Scheduling periodic status update meetings as appropriate.
12. Ensuring that the CIRT follow set procedures in responding to
incidents and that documentation of events is comprehensive.
13. Escalating the incident information to department management.
Providing a contact point for support departments.
1.
2.
3.
4.
14. Technical Team members are responsible for the following:

Promptly responding to queries and requests from the Team Leader.
Participating in evaluating and resolving incidents.
Accurately and comprehensively documenting their actions.
Evaluating the incident response.
15. The Welfare role (optional) is responsible for the following:
16. Ensuring team members have access to the premises outside
regular working hours if required.
17. Organising safe parking for team members outside regular
working hours.
18. Provision of refreshments for team members required to work
long hours. Transport to and from work, if required.
Note: All members of the ICT Department are potential Technical and
Support Team members.
xiv.
Users
b. Users should immediately report any suspicious activity that may indicate a
security incident is in progress to the Help Desk administrator. For example
virus warnings, unusual behaviour of the workstation, unreasonable figures
in applications, denial of service etc.
xv.

a. IT department managers work with the CIRT leader to provide the required skills
to execute this IRP. In addition, Managers ensure that their staff know the
xvi.
reporting procedures contained in this document and are aware of the IT

Procedures manual of the Organisation.
a. System Administrators report any suspicious activity or actual technical faults on
the network infrastructure (devices, servers etc.) to the CIRT leader. They may
also be called upon by the CIRT leader to determine and implement a solution.
xvii.
a. Security Administrators report any suspicious activity reported by the monitoring
tools to the CIRT leader. They may also be called upon by the CIRT leader to
xviii.
Support Departments
a. Support departments include Administrative Services, Human Resources,
Security, and Legal who may be required to participate in resolution of the
incident. ITD management will request them for support in incidents that require
their involvement for example if the incident is caused by a power failure or is
deliberately caused by a staff member or if there is likely to be violence.
Request will be made according to the communications plan (Appendix A).
b. When support departments participate in incident resolution, they will be
responsible for accurately and comprehensively documenting their activities and
submitting the report to the CIRT leader. Activities will be recorded in the
Actions Taken Form (Appendix B).
xix.
Vendors
a. Vendors work with the CIRT team to resolve the incident.
Threat Environment
i.
The threat may be from an internal source i.e. any person authorised to
access the Organisation Network (employee, contractor, consultant, external
support staff, etc.) or from an external source i.e. one without authorised
access to the Organisation Network services.
ii.
A security incident will immediately be classified as a Type II incident and

escalated to the CIRT Leader.
Technical Incidents
i.
Hardware Failure; Failure of infrastructure that leads to a disruption of any
Organisation Network service for more than sixty (60) minutes. Infrastructure
includes network devices, cabling, servers and the components included therein
e.g. hard disks and interface cards.

ii.
Software Failure; Failure of any operating system or application that leads to a

disruption of any Organisation Network service for more than sixty (60) minutes.
This does not include software on workstations which will be handled as Incident
Type I
iii.
Configuration Incidents; Configuration changes that cause disruption to any

Organisation Network service for more than sixty (60) minutes.
iv.
Power Failure; Loss of power to any Organisation Network component that leads
to a disruption of any Organisation Network service for more than thirty (30)
minutes.
Note: The minimum Recovery Time Objective for Organisation Services is sixty (60)
minutes for critical systems.
Security Incident
i.
Malicious Code Attacks; Viruses, worms, Trojans, and spyware that lead to a
disruption of any service on the Organisation network.
ii.
Hacker/Cracker Attacks ; An individual (internal or external) who attempts to

gain unauthorised access to applications, devices or services to cause damage
or gain information or perform illegal activity.
iii.
Denial of Service Attacks; An explicit attempt to prevent legitimate users from

accessing an Organisation Network service by: flooding the network, thereby
preventing legitimate network traffic, disrupting connections between two
machines, preventing a particular individual from accessing a service, disrupting
supporting services such as power and environmental controls.
Failure of Service Provider

i.
A failure of a service provided by external parties (e.g. telecommunications links,
website hosting and email transmission) disrupting regular operations for more
than sixty (60) minutes.
51.8 Flow Chart
Figure 31: Contingency Planning flowchart
52 Organisation/ICT/02/01/Annex 10 - Security Incidents

52.1 Description
Security incidents must be captured and analysed in a manner allowing timely corrective action
to be taken. A security incident owner must be assigned from Organisation Information Security
for all Organisation
52.2 Objective
The objective of this Guideline is ensure that all Incidents falling under the respective classes
are identified and reported
52.3 Scope
This Guideline relates to all system related incidents for Organisation systems

A clear point of contact must be established for all employees, contractors and third party users
allowing them to raise information security incidents.
A point of contact must be available to respond to information security incidents at all times.
All users (including third party users) of Organisation IT Services must be made aware of their
responsibility to report suspected or actual information security noncompliance, and incidents,
and the correct process for reporting information security incidents.
The security incident owner must track the information security incident to resolution and
closure.
All users (including third party users) made aware of an information security incident must report
it to the central information security incident response team in Organisation Global Information
Security
52.5 Responsibility
Roles
CIRT
Users
Help desk
Responsibilities
1. identify all security incidents
2 log the security incidents
1. Identify all potential security incidents
and report to help desk
1. record all potential incident for
evaluation by the CIRT
52.6 Procedure
Identification of the nature of the incident involves 8 steps which have been outlined
below;
Activity
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Description
Determine systems or services
affected, symptoms and
frequency
Report to CIRT leader
Determine if it is an incident
Determine whether to block
activity
Record incident information in
Incident Report (Appendix 1.4)
Activate CIRT
Determine whether and who to
notify: System owner, all staff
etc. according to
communications plan( If
Available)(Appendix 1.1)
Decide whether to escalate to
Strategy and Risk Management
or Audit. If escalation is agreed
perform actions in XXX
Actor (s)
Service Desk / User Support /
Technical Support/security
operations
Service desk / user
support/technical support/security
operations
CIRT leader in consultation
CIRT leader in consultation
CIRT leader
CIRT leader
IT dept. management in
consultation with CIRT leader
IT dept. management in
consultation with CIRT leader
Please note the following;

i.
Note 1: Activities are performed sequentially
ii.
Note 2: Only the people required to know about the incident should be notified.
iii.
Note 3: All notification from the CIRT will be through the CIRT leader and this should be
according to the communications plan. If the email is unavailable, information for all
staff will be communicated to Departmental Risk Liaison Officers and Secretaries in
addition to notice board posts. (Appendix XX).
iv.
Note 4: In the absence of the CIRT Leader and deputy, the decision to block the activity
will be made in consultation with any ITD manager. In the absence of IT department
management as well the System Administrator or Security Administrator will make the
judgement on whether to block the activity
52.7 Reference
Ref
Document name
ISO 27001 and ISO 27002 Standards
Information Technology Infrastructure Library (ITIL
Control Objectives for Information and Related Technology (COBIT)
52.8 Flow Chart
Figure 32: Security Incident Flowchart

Guideline Name
Organisation/ICT/02/01/24 - General
Software Guideline
R.1
Organisation/ICT/02/01/Annex 9 Contingency Planning
Organisation/ICT/02/01/Annex 11 - Incident
Logging / Identification and protecting
evidence
R.3
R.2
Organisation/ICT/02/01/Annex 13 - Escalation
of Incidents to disaster management
53 Organisation/ICT/02/01/Annex 11 - Incident Logging /

Identification and protecting evidence
53.1 Description
A process must be established for managing information security incidents that require forensic
investigation. The process for obtaining independent, documented approval for forensic
investigations must be documented and maintained.
53.2 Objective
The main objective is to preserve evidence for further investigation, for use in the
evaluation phase, to improve protection and procedures, and for use in case the Organisation
decides to take legal action.
53.3 Scope
Information security incident management process includes:
i.
procedure for conducting a forensic investigation
ii.
guidelines on identifying situations that require forensic investigation
iii.
a point of contact for initiating the forensic investigation process
iv.
roles and responsibilities of any parties who may be involved in a forensic

investigation
v.
Details of how the process complies with a published standard or code of practice
for the recovery of admissible evidence.

Keep a chain of custody i.e. who had it, where they kept it, dates, times. Use the Actions Taken
Form (Appendix 1.4)
Perform a full backup of the system, preferably on write once media, and secure the backup
media. (This applies to security incidents only.)
Date and sign notes, printouts and logs and keep in a secure place.
Note 1: Activities are not performed sequentially.
53.5 Responsibility
Roles
End Users
User Help Desk
Responsibilities
1.Identify all potential incidents
2.Log the incidents with Help
desk
1.Record all incidents
2. Escalate the incidents to the
CIRT for action
53.6 Procedure
The forensic investigation approach must include steps to:
Establish and document a chronological sequence of events log investigative actions
Demonstrate that evidence has been collected and preserved in accordance
with guidelines and best practice rules of evidence and chain of custody
Secure target IT systems
Ensure that processes used to create and preserve evidence can be repeated
by an independent third party
Limit information to authorised individuals and ensure that it is kept confidential.
Include steps to classify the information in accordance with the CRCB
Information Classification Standard
Relevant results from the forensic investigations must be reported to authorised senior
management, legal, or regulatory bodies as required.
Forensic investigations must only be carried out by authorised individuals.
53.7 Flow Chart
Figure 33: Incident Logging / Identification and protecting evidence flowchart
54 Organisation/ICT/02/01/Annex 12 - Containment of
Incidents
54.1 Description
Containment of incidents is critical and there is need to limit the magnitude of an incident as
quickly as possible and not to let it continue in order to get evidence.
54.2 Objective
The main objective is to preserve evidence for further investigation, for use in the
evaluation phase, to improve protection and procedures, and for use in case the Organisation
decides to take legal action.
54.3 Scope
This Guideline relates to all system related incidents for Organisation systems result

Once incidents are identified measured should be put in place to ensure that the incident does
Only CIRT members with the support of IT technical team shall be authorised to contain the
incident(s).
54.5 Responsibility
Role(s)
ICT Department
Responsibilities
1. Contain all identified incidents by
isolating the problem
CIRT
1. Authorize containment of the identified

incident
2. Monitor the containment process and
preparation for next course of action
3. Identify and report immediate incident
impact
54.6 Procedure
The procedure for containment of incidents is as below;
Determine the cause of the incident
Determine the source of the incident
Determine the appropriate response:
1. whether to isolate a system, segment or service
2. Whether to shut down a system or service. whether to change passwords
and the particular passwords that must be changed i.e. specific system
passwords, or all users passwords
3. Any other response
Provide updates to IT department management as detailed in the communications plan
Contact all possible support options, internal and external to Organisation.
Contact the Vendor Manager
Decide whether to escalate to SRM.
Diligently record all observations, assumptions, decisions, actions, people spoken or written to,
date and time.
If the attack is network based, the team should be careful not to alert the intruder. Avoid a flurry
of email or other in-band communication, a change in established routines, indiscrete
discussions etc.
In the absence of the CIRT Leader and deputy, determining an appropriate response will be
made in consultation with any IT department manager.
In the absence of IT department management as well, the System Administrator or Security
Administrator will make the decision.
If a system is suspected of being compromised, do not log in as root or Administrator if
it can be avoided.
Consider use of relay teams in the CIRT if the incident requires working late hours. Team
members should not work more than 12 hours at a time.
Refer to the list of IT department staff contacts. A comprehensive list of contacts (internal and
external) to be maintained on the IT Intranet webpage or with the Vendor Manager.
Document all the lessons learned
54.7 Flow Chart
Figure 34: Containment of Incidents flowchart
Guideline Name
Logging / Identification and protecting
evidence

R.1
R.2
Organisation/ICT/02/01/Annex 13 - Escalation
of Incidents to disaster management
R.3
Organisation/ICT/02/01/Annex 14 252 | East Africa Public Health Laboratory Network Project
Eradication of incidents
55 Organisation/ICT/02/01/Annex 13 - Escalation of Incidents

to disaster management
55.1 Description
Incident management involves escalation of incidents. Incidents at times result into disaster and
there is need for a formal team and process to determine when to escalate an incident to
disaster
55.2 Objective
The main objective is an orderly transfer of incident management from this Incident Response
Plan to Disaster Management.
55.3 Scope

Computer incidents shall be separate from the Organisation disaster management incidents.
All identified disaster management incident shall be escalated to the disaster management
team.
55.5 Responsibility
Role(s)
CIRT
Responsibilities
Escalate disasters to the disaster
management team based on the
organization business continuity plans
and disaster recovery plans
55.6 Procedure
The procedure for escalating incidents includes;
Formally escalate to Strategy and Risk management department
Compile known information for handover to Recovery and Resumption Team Leader (Refer to
Organisation Disaster Recovery Plan)
Continue containment activities until Disaster declaration is made
Hand over leadership to Recovery and Resumption Team Leader
Store evidence in a secure location
Compile and store incident records
55.7 Flow Chart
Figure 35: Escalation of Incidents to disaster management flowchart

Section
Reference
Guideline Name
54
Organisation/ICT/02/01/Annex 12 Containment of Incidents
R.2
56 Organisation/ICT/02/01/Annex 14 - Eradication of
incidents
56.1 Description
Eradication of incidents is important to Organisation in order to prevent re-occurrence of the
incident
56.2 Objective
The main objective is to remove all traces of the incident and prevent recurrence.
56.3 Scope

All traces of system incidents must always be removed so as to prevent re-occurrence
Responsibility
Role(s)
CIRT
Responsibilities
1. Eradicate incident based on the
agreed resolution procedures
2. Document the lessons learned and
update the incident resolution register.
3. share the knowledge with the rest of
the organization
56.5 Procedure
In order to eradicate the incident, the following should be performed
Remove or resolve the cause of the incident.
Implement appropriate protection techniques to prevent recurrence
Perform vulnerability analysis on systems connected to the affected system.
Resolve any incident related issues
56.6 Flow Chart
Figure 36: Eradication of incidents flowchart
57 Organisation/ICT/02/01/Annex 15 - Incident Recovery

57.1 Description
Incident recovery involves a number of procedures which are all focused towards restoring the
system back to its original state
57.2 Objective
The main objective is to restore the affected system(s)/devices to their normal mission status.
57.3 Scope

The CIRT shall be responsible for coming up with recovery procedures for the incidents
As part of recovery the CIRT shall maintain and refer to previous incident logs for reference in
recovery.
Once recovery is successful the recovery procedure shall be recorded in the lessons learnt and
recovery procedure in the incident log
Only members of the CIRT and competent IT Technical staff shall be allowed to manage the
recovery process
57.5 Responsibility
Roles
CIRT
Responsibilities
1. Implement incident resolution
procedures.
2. Confirm that the incident has been
resolved.
3. Carry out confirmation test
4. Inform the organization that the
incident has been resolved.
57.6 Procedure
Determine what needs to be done to restore affected systems
Define recovery action plan
Get the necessary approvals for recovery actions
Implement the recovery decisions
Test the affected systems/devices

Put affected system(s)/device(s) back into production
Monitor the affected systems/devices for the agreed period including verifying system and
network logs.
Monitor recovery activities
a. Note 1: Activities are performed sequentially.
b. Note 2: Diligently record all decisions and activities
c. Note 3: Consider use of relay teams in the CIRT if the incident requires working late
hours. Team members should not work more than 12 hours at a time.
d. Note 4: Refer to Appendix G for a list of ITD staff contacts. A comprehensive list of
contacts (internal and external) is maintained on the IT Intranet webpage or with the
Vendor Manager.
57.7 Flow Chart
Figure 37: Incident Recovery flowchart

Guideline Name
Organisation/ICT/02/01/Annex 12 Containment of Incidents
Closure

R.1
R.2
58 Organisation/ICT/02/01/Annex 16 - Evaluation of Incident

Reports
58.1 Description
All incidents must be recorded and reports maintained for future reference
58.2 Objective
The main objective is to improve incident management in the department.
58.3 Scope

The CIRT team shall be responsible for evaluating the incident report with the objective of
updating the incident log as well as educating the CIRT team
58.5 Responsibility
Department
CIRT
Role(s)
1. Evaluate the incident report
2. Determine root causes
3. Put in place mitigation
recommendations
4. inform the organization where
necessary
58.6 Procedure
Determine the response quality to the incident
Determine the incident costs including staff time, recovery purchases, outage time, vendor costs
and legal costs if any and include in Incident Report
Review existing Guidelines and procedures in light of the incident.
Submit Incident report that includes lessons learned, costs, resolution timeframes and Guideline
or procedure amendment proposals.
Determine action items to improve incident management
Submit lessons learned information to ITTC for inclusion in security awareness courses.
Update Risk Register
Note 1: Activities are not performed sequentially
58.7 Flow Chart
Figure 38: Evaluation of incident Reports flowchart

Guideline Name
Flow chart Reference

R.2
Organisation/ICT/02/01/Annex 9 Contingency Planning

Recovery
R.1
59 Organisation/ICT/02/01/Annex 17 - Incident Closure

59.1 Description
Closure of incidents is an important aspect of incident management. When an incidents is
resolved, it is important to close the incident showing the action taken, date of closure,
time and who closed off the incident
59.2 Objective
To ensure that all incidents are closed off successfully and evidence is maintained for
future reference
59.3 Scope

Once an incident is resolved a formal closure process should be initiated through the CIRT
All information about the incident must be recorded and stored for future reference
59.5 Responsibility
Department
CIRT Team leader
Role(s)
1. Ensure that the incident has been
closed
2. formally close the incident
3. Inform the CIRT
59.6 Procedure
Closure of incidents involves;
Storing evidence in a secure location
Formally disbanding CIRT by communication to their managers
59.7 Flow Chart
ICT Guidelines and Procedures Manual
Figure 39: Incident closure flowchart

Guideline Name
Organisation/ICT/02/01/Annex 16 Evaluation of Incident Reports
- 266 - | East Africa Public Health Laboratory Network Project
60 Organisation/ICT/02/01/Annex 18 New User Form
NEW USER REQUEST FORM

APPLICATION BY STAFF FOR AN ICT NETWORK AND/OR EMAIL ACCOUNT
Please ensure your Head of Department/Section signs this form.

Complete this clearly and fully using BLOCK CAPITALS.
Return the completed form to ICT Department.
Please note that an initial password will be created for you. For security reasons, please
log in and change your password as soon as possible.
When you leave the Company, your account will be disabled.
* * * * Illegible or Incomplete Forms Will Be Returned * * * * *
START DATE:
TITLE (MR/MRS/DR. ETC):
FORENAME(S):
SURNAME:
DEPARTMENT:
POSITION:
NB: Only to be completed if you require additional access. Please tick the box of
specific access required:
Email Account
Internet Access
Laboratory Information System
Hospital Management information system

TO BE SIGNED BY HEAD OF ABOVE MENTIONED DEPARTMENT/SECTION:
Name:
Dept:
I hereby confirm that the aforementioned will be/is a member of my dept and requires an
IT Network Login and E-Mail account (delete E-mail if not required):
SIGNED (HOD/HOS):___________________________________________________
I.T. Use Only:

Username: _________________________E-Mail: _____________________
Help Desk Call logged for configuration Ref Number: _______________________
61 Organisation/ICT/02/01/Annex 19 Deletion of
Account form
DELETION OF ACCOUNT FORM
NOTIFICATION OF COMPANY LEAVER (FOR AN ICT/EMAIL ACCOUNT)
Please ensure your Head of Department/Section signs this form.

Complete this clearly and fully using BLOCK CAPITALS.
Return the completed form to ICT Department.
Please note that unless specified, all accounts will be disabled and data archived to tape.
If you require data to be transferred to another person, please specify.
ACCESS WILL BE TERMINATED ONE DAY AFTER THE FINAL DATE.
* * * * Illegible or Incomplete Forms Will Be Returned * * * * *
FINAL DATE:
TITLE (MR/MRS/DR. ETC):
FORENAME(S):
SURNAME:
DEPARTMENT:
LIST DATA TO TRANSFER:
TRANSFER OF DATA TO WHOM:
Please specify known access of additional applications/systems.
Email Account
Internet Access
Laboratory Information System
Hospital Management information system
TO BE SIGNED BY HEAD OF ABOVE MENTIONED DEPARTMENT/SECTION:
Name:
Dept:
I hereby confirm that the aforementioned is leaving/has left the employ of Organisation
and his/her I.T. Systems access can be removed as specified above.
SIGNED (HOD/HOS):___________________________________________________
I.T. Use Only:

NT Account disable:
E-mail Account Removed:
Other Account(s)
Removed/Help Desk Ref Number: ________________________________________
62 Organisation/ICT/02/01/Annex 20 Change
Management form
CHANGE MANAGEMENT FORM

CHANGE CONTROL REF. NO.:
APPLICATION/SYSTEM:
VERSION TO BE CHANGED (if applicable):
ISSUE/DESCRIPTION SUMMARY:
RAISED BY:
Signature (Sponsor)
PRIORITY
HIGH:
Name
MEDIUM:
REQUIREMENT DATE (if known):
ESTIMATED TOTAL EFFORT/DURATION (time):
Date
LOW:
BUSINESS IMPLICATIONS
DETAILS:
SYSTEMS/INFRASTRUCUTRE IMPLICATIONS
DETAILS:
DEVELOPMENT REQUIREMENTS (if applicable):
IT APPROVAL
RECOMMENDATION:
SIGNATURE:
] APPROVED
NAME:
] APPROVED WITH MODIFICATION (EXPLANATION


BELOW)
[
] NOT APPROVED (EXPLANATION BELOW)
DATE: ____/____/____
[
] FURTHER ANALYSIS REQUIRED (EXPLANATION
BELOW)
EXPLANATION:
BUSINESS OWNER(S) APPROVAL

RECOMMENDATION:
SIGNATURE:
NAME:
] APPROVED
[
] APPROVED WITH MODIFICATION (EXPLANATION
BELOW)
[
] NOT APPROVED (EXPLANATION BELOW)
DATE: ____/____/____
[
] FURTHER ANALYSIS REQUIRED (EXPLANATION
BELOW)
SIGNATURE:
EXPLANATION:
NAME:
DATE: ____/____/____
IMPLEMENTATION
SIGNATURE:
DATE IMPLEMENTED:
____/____/____
63 Organisation/ICT/02/01/Annex 21 Computer
Equipment Purchase/Requisition form
Computer Equipment Requisition/Purchase Request Form
Department
Type of Request
(Check one)
Date
Replacement
Additional
Standard Computer Equipment Requested

Equipment
Check
Model
Tablet
Notebook
Desktop
Printer
Scanner
Other
Justification (Include information about how the equipment will be used and
by whom. If you are requesting high-end specifications, be very explicit about
the function that requires)
Non Standard Computer Equipment Requested

Technical Specifications
Justification (Include information about how the equipment will be used and
by whom. Be very explicit about the function that requires non-standard
equipment)
Computer Equipment to be Assigned To

User name
Office #
Computer Equipment to be Replaced

Inventory Number/s
Currently assigned to
Responsible Signature: ..
Print Name: .
Request Status (ITC use only)
Approved (Yes No)
Date
Remarks
64 Organisation/ICT/02/01/Annex 22 - Codification
Framework for ICT Guidelines and Procedure Manual
Codification Framework
We propose a codification Framework for Organisation Documents in which all documents
developed would be referenced in the following manner:
[Organisation/UNIT/CATEGORY OF DOCUMENT/NUMBER OF DOCUMENT or NAME]
For Example;
LEVEL ONE
(Company)
Organisation
Organisation
Organisation
Organisation
LEVEL2 (Unit)
[Department]
[Department]
[Department]
[Department]
LEVEL 3
(Classification),
MANUAL
GUIDELINE
FORM
FORM
LEVEL 4 (Name or
Number)
ICTSOPs
01
02
01
This framework is based on ISO 97001.

This framework is meant to be a coherent reference to all documents in the Organisation
and to ensure that all documents in all units have unique references. If a unit has, say, more
than one manual, then these manuals can still be referenced uniquely.
The codification is based on a four-level nomenclature for all documents where (as shown in
the table above):
Level 1: Refers to the Organisation and allows documents to be referenced from outside the
Organisation. It makes documents unique to the Organisation
Level2: Calls to the Unit/department within the Organisation and allows documents to be
uniquely referenced within Organisation
Level3: Classifies documents within a unit into sub categories of Manuals, forms, reports,
Guidelines, etc. NOTE: This level will use codes as shown in the Document categories
below.
Level 4: This is the name or number of a given document. This allows documents to be
unique within a given classification. It also allows documents to be versioned since they can
retain the same name but have different version numbers.
Note: All operational Manuals will have to be given names/numbers within this framework
and reference as such in the ICTSOPs.

Document Classification
Organisation/ICT/2/2
Ref. No
1
2
3
Type
Guidelines
Manuals
Staff matters
4
5
6
7
General Correspondences
Board and Government communications
Legal matters Agreements, Contracts, court
issues
Audit
8
9
Procurement tenders,
Forms
10
Description
Guideline documents
Operational Manuals
Internal memos, letters to
staff
Letters, etc.
Internal and external audit

matters/queries etc.
Data input forms, survey
forms, etc.
65 Organisation/ICT/02/01/Annex 23 - Project Documentation Template
LOGO
Project/System Name XXX < the project name>

Document Type: Project Overview Document
<All project documents should be put under change management on initial creation>
<TEMPLATE INSTRUCTIONS: REMOVE ALL TEXT IN THIS STYLE AFTER YOU HAVE COMPLETED THE SECTION. REPLACE ALL TEXT IN Normal
STYLE.
<The change log should be updated for every significant change made to the document. Use the format n.m for the version number>
Version
Description
Changed
By
Date
1.0
First draft
__________
______
Table of Contents

<The table of contents should be created to guide the reading of this document and should be self-updating>
Introduction/Background
Problem Statement
The problem of . causes.. which means that
<1to 3 sentences describing the business problem for which this system is the solution>
3. Solution Statement
1. The XXX System will
<a 1 to 3 sentence description of how the system will solve the problem described in the problem statement including the benefits of the system to the
business.>
4. Positioning
The XXX System replaces the MMM system currently in use. The XXX System will interact with the yyy system and the zzz system providing
nnn services to its users.
<a paragraph describing the positioning of the system relative to other systems or business processes currently in use. If this is a product that is offered for
sale, describe the positioning of the product within the market >
5. Business Process
The XXX System automates the business process described in Business Process Model

<describe the business process that this system automates. If a business process model has been developed, then change the hyperlink reference to where
this is available. This could be a web-based model in HTML exported from a case tool>
6. Key Features
Feature 1
Feature 2
<10 to 20 bullet point features of the system. Include, technology as well as functionality if it is a particular feature. These will be elaborated in detail in the
Use Case Model and the Non-functional Requirements. Include the order in which they are to be implemented if known e.g. Stage 1, 2 and 3 features.
Change the hyperlink to point to these models/documents>
7. Stakeholder Types Including Users

Stakeholder Type
Description
Stakeholder type name <name of a

stakeholder type>
Stakeholder description <a single sentence

description of how the stakeholder is affected by
the system development>
User Type
Description
User type name <name of a user type>
User description <a single sentence description

of how the user will use the system>
<a stakeholder is anyone who is substantially and materially affected by the system development. This list of stakeholder and user types will be used to
gather stakeholder requirements in order to ensure that all requirements are given proper consideration. User is a sub-type of stakeholder>
Refer to Stakeholder Needs List for details of requirements gathered from the above stakeholder types <change the hyperlink to point to the

stakeholder requirements model file (Excel) or the stakeholder requirements report for the project>
8. Major Implementation Constraints

8.1 Business Constraints
XXXXX <include short (1 to 3 sentence) descriptions of known major budget, timescale and resource constraints. This should be at a summary level rather
than at the detailed level described in the Project Plan. Resource constraints include, for example, the lack of availability of key personnel known to be
committed to other projects or lack of experience in key technologies described in the next section. >
Refer to the Project Plan for more details
8.2 Technical Constraints

XXXXX <include short (1 to 3 sentence) descriptions of specific known major constraints in the areas of: usability: reliability: performance: infrastructure
requirements: languages: operating systems: standards; maintainability: system interfaces: legacy systems and databases. This should be at a summary
level rather than at the detailed level described in the Non-Functional Requirements Document for the project. >
Refer to the Non-Functional Requirements Document for more details
9. Major Risks and Dependencies

XXXXXX <list the major risks that might cause the project to fail. Project failure is defined as failing in any one of providing all the functionality
originally specified, coming in on time, coming in on budget. This should be at a summary level rather than at the detailed level described in the
Risk List for the project. Include any dependencies on outside influences, for example, depending upon other software currently being
developed becoming available on time>
Refer to Risk List for more details
Requirements Decision Making Process

All requests for changes to requirements must be added to the Stakeholder Needs List. The Stakeholder Needs List should regularly be
reviewed by the Requirements Decision Making Board, which will consist of the following:
Project Role
Name
Product Sponsor
Project Manager
Business Analyst
User
Analyst/Programmer
Support
Test Developer
<adjust and complete the above table as required>
Email
Appendix A - Diagrams
A.1 XXXX Model <name of the diagram or model being included>
<insert the diagram here.>
File Reference: file_name.doc < If it is maintained outside of this document and copied into it, give a reference to the model file name>
Date created/copied into this file: nn/mm/pp <insert the date here>
<add any further diagrams that are deemed relevant to summarizing the project>
66 Organisation/ICT/02/01/Annex 24 - ICT SOPS Terms of reference Mapping
Scope Area of the ICT SOP based on the terms of
Domain Alignment Area
reference
Mapping

1. SOPs Policies and Guidelines on IT Users support
Incident Management
and Incident Tracking and Resolution to ensure that
Help desk
all IT and non IT staff of EAPHLNP are able to
Change Management
trouble shoot all computer minor problems and to
Service Level
Management
keep a log of problems and solutions;

a.
Help users in day to day IT problems such as

logging into the network printing to network
printer, salvaging deleted files, monitor problems
Administration
network
of
software,
infrastructure
hardware
including
All user support is managed through the help desk within the IT Department. An ICT
SOP on help desk has been developed to manage day to-day support of users on
issues related to computer hardware, software and Networks and provides the process
to be followed. IT is the responsibility of the ICT personnel to resolve the problem
based on their capabilities.
Incident Management
There are some incidents that a logged with the IT department that may not be the
not affecting server configuration files etc.

b.
Helpdesk
and
files,
routine problem e.g. server, database crush that may result in disruption of the
business of the entire business. These are referred to as incidents and there are
applications, communication, web, e-mail, and
procedures that have been developed under incidents to manage the situation until
domain servers and data bases.
such a time that the business resumes normal operations.
c.
Software installation
Change Management
d.
Network
security
for
satellite
network
infrastructure.
e.
PC
Operating
environment (see definition). The changes come in the form of upgrades, configuration
Systems
Installation
and
Upgrades
f.
Keep log users complaints and support/solutions

provided.
g.
Provide technical support for the use of satellite

software such as OS, Office applications, other
software Including installation, configuration,
backup etc...
h.
Change management deals with changes that are implemented to the computing
Electronic network with other labs in the country
changes. This procedure covers hardware, software and Network.

Service Level Management
This SOP manages the contractual relationship business the organisation and service
providers who manage or support the Network, Hardware and Software. Given that all
incidents, issues, logs are channelled through the IT helpdesk, IT will not be able to
resolve some of the problems themselves e.g when internet is down they would need
to contact the service provider based on the contract/Service level agreement they
have with the service provider.
The ICT SOPS have been developed based on the following Pseudo code;
1. User/Business raises an issue with the Help desk

2. Help desk loges the issues and determines if its something that
the ICT team can troubleshoot.
3. If the IT team can troubleshoot the problem then
troubleshooting occurs and issue is resolved.
4. If the issue cannot be resolved in the IT Department then
escalation occurres by contracting the service provider through
the Service level Management until the issues is resolved
5. Depending on the issues raised it may result in changes to the

2. SOPs
Policies
and
Guidelines
on
Periodical
Support and
Support and Maintenance
Maintenance;
A procedure have been put in place for the process of maintenance and the apply to all
maintenance of workstations, scanning hard disks
Anti-Virus;
forms of maintenance preventive maintenance. It should also be noted that
ensuring virus protection) of the following;
Service Level
maintenance activities can are also performed within the organisation and are done by
management
external third parties as part of the warranty or service contract.
hardware
equipment
maintenance
(Preventive
a.
Computers
b.
Printers
Anti-Virus
c.
Photocopying machines
Anti-Virus procedure and guidelines have been described as a separate policy and
d.
Scanners
these policy are targeted at all the users including the ICT department
Service level Management
Service level management guidelines and procedures are responsible for invoking
maintenance procedures that are contractual with the organisation
Notes
The terms of reference have mentioned maintenance to apply to specific hardware i.e.
printers, computers and photocopiers and scanners. Maintenance should also apply to
all computing and networking hardware (routers, switches, firewall, digital projectors).
Maintenance can also apply to software.
The ICT SOPs have been developed based on the following pseudo code
1. All maintenance calls are logged using the maintenance

procedures
2. All maintenance procedures that may require a third party should
be executed using the service level management
3. An anti-virus SOP has been developed inorder to cater for antivirus.

3. SOPs, Policies and Guidelines on LANs: Servers,
Physical Security and
Physical Security and Environment al Controls
Environmental Controls
This ICT SOP deals with best practice of the ICT environment on provide guidelines on
networking equipment;
Back-up
how to protect ICT hardware equipment, cabling and wiring and protection of the ICT
a.
Server, network monitoring and maintenance;
Incident Management
hardware equipment and general ICT environment. It also deals with UPS battery
Routers, Switches, Cabling, Wiring and associated
b.
c.
Routine check-up of server functionality through
Help Desk
which is expected to protect computing equipment in cases of power failure.
monitor utility, usage of memory, cache buffers,
Back-up
dirty cache buffers, resource utilization.
Anti- Virus
Full procedures on back up have been developed to also include the requirement of
UPS
Service Level
Server backup/restore
Management
Anti-virus
Security Monitoring
The antivirus SOPs have been developed to manage the inter organisation or
battery status and to replace when
necessary
d.
Protecting the servers and data (data security,
virus scanning.
enterprise including protecting servers and scanning.
e.
Server backup/restore
Help desk and Incident Management
f.
Maintaining logbook for server and network
All server and network problems shall be logged with the help desk using the help desk
problems.
ICT SOPs. Depending on the severity of the problems should these problems also
cause significant business disruption then the incident management procedures should
be invoked.
Support and Maintenance, Service level management

4. SOPs,
Policies
and
Guidelines
on
Email
management
a.
b.
Email
Email
ICT Systems Access
The email ICT SOP cover usage and management of the email within the organisation,
control
the Email ICT SOPs covered the creation of users for email briefly however for greater
Manage the Email server to ensure smoothly

functioning of email service
Change management
detail on the process the ICT Access control should be referred to as is covered all
Coordination with internet service providers
Service Level
standard procedures to be followed in ICT Systems Access Controls and the change
Management
management procedures are important for managing users access rights such as
addition or removal as well as creation and deletion of the users accounts
(ISP) for any problems

c.
Create new email account, set up and configure
mail client for users

d.
e.
Ensure additions of joiners and removal of
leavers accounts to the
The relationship between the organisation and the ISP should be managed through the
Security, Confidentiality of data used by Internet
contract between the two organisations hence the service level management ICT
and Web based systems
SOPs.

5. SOPs, Policies and Guidelines on Data back-up/
Security Monitoring
Back up
Disaster Recovery and Business continuity; Include
Incident Management
The back-up ICT SOPs cover all back up requirement as outlined in the terms of
system security and encryption as appropriate
Back Up
reference including additional requirement based consultation with the requirement with
a.
Acceptable use
the various organisation.
Ensure compliance in terms of data backup and

storage
b.
c.
d.
Complete back up of users volume of the server
Incident Management
disk.
Incident Management procedure is responsible for business continuity and Disaster
Incremental backup will be taken on the same
recovery by assisting the organisation in business resumption in cases of Incident or
cartridge at least twice a week.
disaster.
Server backup a long with server scripts

information.
Acceptable use
Acceptable use are referenced in this section to manage the compliance with this
particular ICT SOP
Notes on Encryption and Security
On data Encryption and Security it is important to ensure security of data in storage
and when data is being transmitted
Therefore encryption has been managed as follow
For data transmission and storage this is a covered in the following SOPs
a)
b)
c)
d)
e)
Email - encryption and Digital signatures

Wireless Network Access
Third party network access
Software Security Requirements- Encryption of Web Application
Removable Media

6. SOPs, Policies and Guidelines on Applications and
Project Management
The various SOPs for this section of the terms of reference have been covered in the in
Systems (Hospital Management Information System
Software development
the following SOPs
(HMIS), Laboratory Information System (LIS)
Security Monitoring
Project Management
e.
Information Management
Back up
f.
System configuration
Help Desk
Security Monitoring
g.
System customization
Change Management
Back up
h.
System upgrade
Help Desk
i.
System maintenance
Change Management
j.
System monitoring
k.
Database analysis
l.
System security
a.
Information Management -
m. Advanced troubleshooting
b.
System configuration Change Management
n.
System database backup and recovery
c.
System customization Software development
o.
System functionality
d.
System upgrade Software development and change management
p.
System maintenance
e.
System maintenance help desk, support and maintenance and Service
q.
System troubleshooting
r.
level management
All procedures required by the end-users to
f.
System monitoring
perform their work
g.
Database analysis
h.
System security Security Monitoring
i.
Advanced troubleshooting Help Desk
j.
System database backup and recovery
k.
System functionality Project Management and Software Development
l.
System maintenance Support and Maintenance
m. System troubleshooting Help desk

n.
All procedures required by the end-users to perform their work

7. SOPs, Policies and Guidelines on Procurement of IT
Procurement
Procurement
SOPs on procurement have been developed however it should be pointed out that
equipment, Software Inventory
they should be in full compliance with the procurement guidelines of the organisation
as well as government
8. SOPs, Policies and Guidelines on Ownership of
regulations
Data, Privacy Issues and Data integrity
9. SOPs on Training
Refer to country specific
Training
Training
An SOP on training has been developed this SOP must be used in conjunction with
the Organisation SOP in training from the Human Resources Department.
10. SOPs on Global Connectivity, Telecommunications

and connections
11. SOPs on Web development, hosting, presence and

content
Network Configuration
Network Configuration, Access, Third Party Network Access
Network Access
These SOPs deal with configuration and access of the network including the type of
Third Party Network
network and the relationship the organisation should have with third parties such as
Access
ISPs who may have access to the organisations network
Development of Web
A full ICT SOP on Software development has been developed to cover the process of
Applications
software development
Software Security
Software Security Requirements
Requirement
This section covers security requirement for software and also covers Web
Applications
SOPs on Web development, hosting, presence and content
An SOP on Web Development hosting and Content has also been developed

12. SOPs on Wireless networking
Network Access
Net Work Configuration
20.
21.
Network Configuration
The purpose of the Organisation Network Configuration ICT SOP is to establish the
rules for the maintenance, expansion and use of the network infrastructure. These rules
are necessary to preserve the integrity, availability, and confidentiality of Organisation
information.
Network Access
To enable Organisation control all connections to its networks in order to preserve the
private nature of the Organisation's network and computing facilities In this section the
Wireless network Access is defined
13. SOPs on Records Management (for records
resulting from the project)
Project Closure, Sign-off

and Retention of project
documentation Refer to
country specific
regulations on retention
14. SOPs on System Security (i.e., of the servers and
Security Monitoring
workstations)
Project Closure, Sign-off and Retention of project documentation

This ICT SOP covers the guidelines and procedures to be taken by the project
manager after a project closure and includes guidelines on document retention. In the
same procedure of document retention there is also a reference to the project manager
to adhere to the retention laws of the country regarding hard copy documentation.

15. SOPs on Compliance with standards (e.g., standards
ICT Responsible Use
from the National Data Center or the Ministry of
Eligibility for ICT

Resources and Services
Health)
ICT Responsible Use

In the context of ICT SOPs ICT responsible use
-To ensure compliance with applicable statutes, regulations, and mandates regarding
the management of information resources in the East African Community Partner
States
-To establish prudent and acceptable practices regarding the use of information
resources.
-To educate individuals who may use information resources with respect to their
responsibilities associated with such use.
Eligibility for ICT Resources and Services
The main purpose of this ICT SOP is to define the eligibility for use of ICT resources.
Organisation ICT resources are for its core business purposes and must be used in
line, and to achieve its core mandate, vision and mission.
Any use counter to this, or which interferes with core use by others, is unacceptable
Specialized information technology services may require additional authorization,
approval, or separate registration as per the User management and Network Access
policies.
16. SOPs on Evaluation of service, IT Audits and IT
Service level
management
Inspections
ICT Assessments (ICT Audits and Inspection)

An ICT SOPs has been developed to manage ICT Assessment covering ICT Audits
and Inspection
ICT Assessments (ICT

Audits and Inspection

The service level management must also be considered as part of any normal review to
review the services that are performed by third parties
67 Organisation/ICT/02/01/Annex 25 - Information Sharing

Guidelines
Information Security requirements specification
Context description of the EAPHLNP Network

Data exchanges
There are two dataflow levels to be distinguished in the EAPHLNP system:
1.
The NATIONAL dataflow level (national domain dataflow): Between the End User, the
National laboratory / IT service supplier, and the National Repository, or, any other
EAPHLNP network related national data flows.
2. The CROSSBORDER - INTERSTATE dataflow level (cross border domain dataflow):

Between the EAPHLNP Partner state and a third party country.
The exchange of data in the EAPHLNP network context can be modelled as follows
1. Authentication and administration Data: Exchanged from End User to National
laboratory, and vice versa. Authentication data clearly identify the End User, and document
its entitlement for the service. Part of this data is added to the logs.
2.
Transactional data: Exchanged between the End Users National laboratory of the
Partner state, and the National laboratory of the Partner state.
3. Validation data: Exchanged between the National laboratory and the End Users.
Validation data may contain customer administrative data, validation decision data,
additional data qualifying the transactions, etc. (existence and content based on general
design).
1.1.1 Legal basis

The following principle applies:
For the NATIONAL dataflow, the actors should respect the respective national legislation
on privacy and data protection and other related national legal provisions in effect.
For the CROSSBORDER (interstate) dataflow, as an East African network, the EAPHLNP
actors/partners will respect at least:
o
EAC framework for cyber laws
1.1.2 Security rules

The following general security rules are specified and apply for the EAPHLNP information sharing
rules:
SR 001
Description
EAPHLNP network data flows must be adequately protected, as specified in

international standards.
SR 002
End users must be clearly identified by National Laboratories before being

able to enter the system.
SR 003
Mutual authentication between End Users and the laboratories is needed

when connecting to the system
SR 004
End user identification and authentication means must have been audited
and certified by an independent organization which is certified by the
national authorities according to best practice international standards.
SR 005
National laboratory Data and Privacy protection procedures in place must

have been audited and certified.
SR 006
National laboratories authentication means must have been audited and

certified by an independent organization which is CERT* certified according

to international standards.
SR 007
Mutual Authentication between National Laboratories of different Partner

state is needed, when initiating a Trans East African (cross border)
information flow.
Rules SR002, SR003, SR004 are a national (national level) competency, while rules SR005,
SR006, SR007 are a pan African (EAPHLNP network level) competency.
1.2
Definition of EAPHLNP laboratories interconnectivity security and

requirements
The following list describes the EAPHLNP laboratories interconnectivity security objectives and
requirements that are identified as critical for the security of the EAPHLNP laboratories
interconnectivity system and processes and form the basis for constructing the Security Policy.
These requirements are based on the security best practices in the field of Health and Laboratory
under the EAPHLNP.
1.3
Security awareness requirements
Security Requirements specifications

1.3.1.1 Make the EAPHLNP network users aware of the risks that threaten the
EAPHLNP laboratories interconnectivity data and processes, and the
information and information systems of the EAPHLNP laboratories
interconnectivity partners, and the available means of protection.
1.3.1.2 Make users aware about information security and train them using the
authentication mechanisms in place. Users must understand the related
standards and policies and recognize and accept the responsibility for
protecting the passwords, tokens, private keys, etc., by signing the related
statements.
1.3.1.3 Implement security awareness program to enhance users trust in the

EAPHLNP laboratories interconnectivity network.
1.3.2 Organizational requirements:

1.3.2.1 Create a general security framework / set of security principles adapted to
the EAPHLNP laboratories interconnectivity information system needs, to be
followed by people that are in charge of EAPHLNP laboratories
interconnectivity processes and put in place appropriate measures and
procedures in order to ensure the information and information system
security.
1.3.2.2 Facilitate the effective governance of shared information assets and

effectively oversee the security management arrangements.
1.3.2.3 Promote cooperation between various actors of the interconnectivity network

in order to elaborate and put in place those measures, instructions and
procedures
1.3.2.4 Ensure that the EAPHLNP laboratories interconnectivity IT infrastructure and

software on which the system is running is up to date, provides all the
necessary security updates and is compatible with national domain systems
in partner states.
1.3.2.5 Ensure that EAPHLNP laboratories interconnectivity processes do not

require unacceptable changes to the local (national competency) systems
already in place.
1.3.2.6 Ensure the separation of duty among EAPHLNP laboratories

interconnectivity actors (identity providers, data service providers, etc.).
1.3.2.7 Ensure that an effective information security incident management process

for the EAPHLNP laboratories interconnectivity infrastructure exists and
contracting parties will cooperate in investigating security incidents.
1.3.3 Legal requirements:
Reference

1.3.3.1 Ensure that the information system in place respects all related National
and East African laws on privacy and data protection in force. This is based
on the following principles:
For the NATIONAL dataflow, the actors should respect:

respective national legislation on privacy and data protection

in effect
For the CROSSBORDER (interstate) dataflow, as an East African

network,
the
EAPHLNP
laboratories
actors/partners will respect at least:
interconnectivity
1.3.4 Technical requirements:

1.3.4.1 All EAPHLNP laboratories interconnectivity data flows must be adequately
protected, covering both the partner state requirements and the agreed
EAPHLNP laboratories interconnectivity minimum standards
1.3.4.2 End Users must be clearly identified by the National Laboratories before
being able to enter the system.
1.3.4.3 Mutual Authentication between National Laboratories of different Partner

States is needed, when initiating a cross border information flow.
1.3.4.4 The national portal server is located in a safe environment, according to

current standards (e.g. physical access is controlled and allowed only to
authorized staff, based on written and accepted statements, following the
general design).
1.3.4.5 Administration access to the National Laboratories is limited to appropriate

staff only (e.g. administrators, security officers). Administrative users are
using appropriate means of authentication (e.g. strong passwords or an
equivalent means like, electronic signatures etc.) issued and used according
to a suitable Certificate Policy. Digital certificates are issued by a
Certification Authority(is) which is appropriately accredited by the national
authorities or equivalent (e.g. the Webtrust programme for Certification
Authorities, the standard framework of AICPA/CISA, tScheme, or
equivalent)
1.3.4.6 The system is using appropriate procedures to ensure data for audit trail
1.3.4.7 Special attention must be given to the Root Certificate Authority, which is
issuing the certificates for the National Portal (Portal to Portal certificates), in
order to ensure that this Certification Authority can be trusted and can be
accepted as root authority. For this purpose the root Certification Authority
must be certified by the national authorities or equivalent (e.g. the Webtrust
programme for Certification Authorities, the standard framework of
AICPA/CISA, tScheme, or equivalent).
1.4 Security Audit requirements:

1.4.1.1 End user identification and authentication means must have been audited
and certified by an independent organization which is certified by the
national authorities or equivalent (e.g. the Webtrust programme for
Certification Authorities, the standard framework of AICPA/CISA, tScheme,
or equivalent)
1.4.1.2 National Laboratories in partner states authentication means must have

been audited and certified by an independent certified organization.
1.4.1.3 National laboratory Data and Privacy protection procedures in place must
have been audited and certified by the responsible national data protection
supervisory body.
1.4.1.4 Each partner states National EAPHLNP laboratories interconnectivity

network Portal must pass through a security audit according to international
standards. The security audit must be repeated yearly.
1.4.1.5 Security audits must be conducted yearly to audit the systems by

ISO/IEC27001, ISO/IEC 17799 / ISO/IEC 27002, or equivalent level
standards, according to the above listed requirements and the technical
recommendations provided by the EAPHLNP in this respect. Security audit
should also cover risk management issues.
1.4.1.6 Audit must approve the fulfillment of the application installation and
operation of security principles and guidelines.
Legal framework
East Africa Public Health Laboratory Network Project, 2013
Arrangement of Regulations
PART I PRELIMINARY PROVISIONS
1. Citation
2. Interpretation
PART II ESTABLISHMENT
3. East Africa Public Health Laboratory Network Project
PART III ADMINISTRATION
4. Composition and functions of the Committee
5. Financial Responsibility for required Infrastructure
PART IV INFORMATION TO BE STORED ON THE NETWORK
6. Data sharing of Health and Labaratories databases of Partner States
7. Externally sourced information
PART V INFORMATION TECHNOLOGY
8. Application of Information Technology
9. Mode of exchange of Information
10. Document Management System
11. Data Security and Integrity
12. Data Storage
13. Back up of information.
14. Incident reporting
15. Operational guidelines
PART VI ACCESS, USE AND CONFIDENTIALITY PROVISIONS
16. Use of Information
17. Confidentiality of information
18. Personal data protection
19. Access to Information

20. Information security Agreements
21. Obligations of users as to passwords.
PART VII: LEGAL EFFECT, AUTHENTICTY AND ADMISSIBILITY
22. Legal effect of information
23. Authenticity of information
24. Admissibility and evidential weight of information kept on the Network
PART VIII OFFENCES AND PENALTIES
25. Unauthorized access to or improper use of the Network
26. Access with intent to commit or facilitate the commission of a further offence
27. Unauthorised modification of computer data
28. Unauthorised use or interception of computer service
29. Unauthorised obstruction or use of computer
30. Unauthorised disclosure of access code
31. Unauthorised disclosure of information
32. Electronic fraud
33. Tampering with the Computer source code
34. Publishing of obscene information in electronic form
35. Publication for fraudulent purposes
36. Enhanced punishment for offences involving protected computers
37. Abetment and attempts
38. Attempt defined
39. Cyber harassment
40. Offensive communication
41. Cyber stalking
42. Compensation
43. Offences by Corporate Body
PART IX MISCELLANEOUS PROVISIONS
44. Jurisdiction
45. Transitional provisions
THE EAST AFRICAN COMMUNITY PUBLIC HEALTH LABORATORY REGULATIONS,

2013
PART 1
PRELIMINARY PROVISIONS
1. Citation and Commencement
These regulations may be cited as the East African Community Health Laboratories
Management (Health Laboratories Interconnectivity) Regulations 2012 and shall come into

force on such date as the Council may, by notice in the Gazette, appoint.
2. Interpretation;
22. In these Regulations unless the context otherwise requires Assignee in relation to users of the Network, means a person to whom an Authorized
User has delegated their duty and therefore right to access information attached to the
Authorized User.
Authorized User means an official of the Laboratory department of a Partner state
nominated as the person who should have access information over the Network and
shall include an assignee.
National Health Laboratories Database means an information depository operated
by the East African Community relating to Health Laboratories matters and fed
information by the Health Laboratories departments of the EAPHLNPpartner states.
Committee means the Committee as established under the East Africa Public Health
Laboratory Network Project
Computer means an electronic, magnetic, optical, electrochemical or other data
processing device or a group of such interconnected or related devices, performing
logical, arithmetic or storage functions; and includes any data storage facility or
communications facility directly related to or operating in conjunction with such a device
or group of such interconnected or related devices;
Computer Service includes computer time, data processing and the storage retrieval
of data;
Computer system (Kenya KICA) means a device or collection of devices including
input and output devices but excluding calculators which are not programmable and
capable of being used in conjunction with external files which contain computer
programmes, electronic instructions and data that perform logic, arithmetic, data storage,
data retrieval, communication control and other functions;
Content includes components of computer hardware and software;
Cyber harassment includes the use of a computer for any of the following purposes
a) making any request, suggestion or proposal which is obscene, lewd, lascivious or
indecent;
b) threatening to inflict injury or physical harm to the person or property of any
person; or
c) Knowingly permitting any electronic communications device to be used for any of
the purposes mentioned in this section.
Damage means any impairment to a computer or the integrity or availability of data,
program, system or information that

a) causes any loss;
b) modifies or impairs or potentially modifies or impairs the medical examination,
diagnosis, treatment or care of one or more persons;
c) causes or threatens physical injury or death to any person; or
d) threatens public health or public safety;
Data means electronic representations of information in any form;
Data Message means data generated, sent, received or stored by computer means;
and includes
a) voice, where the voice is used in an automated transaction; and
b) a stored record;
Directorate means the Directorate of Health Laboratories established by the Council
under Article 75(3) of the Treaty for the Establishment of the East African Community.
Dollar means the United States Dollar and includes the equivalent in the currency of
the Partner States.
EAC means the East African Community
Electronic Device, Acoustic Device, or other device means any device or
apparatus that is used or is capable of being used to intercept any function of a
computer;
Electronic Record means data which is recorded or stored on any medium in or by a
computer or other similar device, that can be read or perceived by a person or a
computer system or other similar device and includes a display printout or other output of
that data;
ICT means Information and Communications Technology
Information includes data, text, images, sounds, codes, computer programs, software
and databases;
Information system means a system for generating, sending, receiving, storing,
displaying or otherwise processing data messages; and includes the internet or any
other information sharing system;
Information System Services includes a provision of connections, operation facilities,
for information systems, the provision of access to information systems, the transmission
or routing of data messages between or among points specified by a user and the
processing and storage of data, at the individual request of the recipient of the service;
Intercept, in relation to a function of a computer, includes listening to or recording a
function of a computer or acquiring the substance, meaning or purport of such a function;
IT means Information Technology
Network means EAPHLNP laboratories interconnectivity Network.

Information means any data, processed or analyzed, and any documents, reports or
any other communication in any format and includes, electronic, certified or
authenticated copies of these;
ISA Information Security Agreement
Partner States refers to the EAPHLNP Partner States
Person includes any company or association or body of persons corporate or
unincorporated;
Personal data means any data concerning an identified or identifiable person;
Program or Computer Program means data representing instructions or
statements that, when executed in a computer, causes the computer to perform a
function;
Team means the technical Team of experts as constituted by the Committee under
Regulation 4(1)
Traffic Data means any computer data relating to communication by means of a
computer system generated by a computer system that formed a part in the chain of
communication, indicating the communications origin, destination, route, time, date,
size, duration or type of underlying service.
WHO World Health Organisation
PART II
ESTABLISHMENT
3. The Health Laboratory Interconnectivity Network

23.
1) Subject to the provisions of and Regulations of the EAPHLNP, there shall be
established a Health Laboratory Interconnectivity Network for the partner states.
24.
2) The Health Laboratory Interconnectivity Network shall be operated under the
institutional framework of the Committee established under EAPHLNP.
25.
ADMINISTRATION
26.
4. Composition and Functions of the Technical Team of IT experts
27.
1) A Team shall be appointed under the directions of the Committee for Health
Laboratories and shall in liaison EAPHLNP.
28.
2) The Team appointed in regulation 4(1) above shall consist of the following;
a) Heads of IT in the Health and Health Laboratories public institutions
b) Health Information systems experts responsible for Health and Laboratories IT
systems

c) Statisticians
d) Legal experts
e) Any other member co-opted by the Committee.
29.
3) The EAPHLNP shall coordinate and monitor the activities referred to in regulation
4(4).
30.
4) The Team shall carry out the following functions in relation to the Network;
31.
a) Advise and recommend on the policies on Health Laboratory Interconnectivity.
b) Advise and recommend on specific programs relating to IT interconnectivity for
implementation in the EAC.
c) Develop and recommend on system design and upgrades
d) Advise and recommend on review of the Regulatory framework.
e) Advise and recommend on quality assurance measures of the systems.
f) Advise and recommend on monitoring and evaluation mechanisms.
g) Any other function as specified by the Committee.
32.
5. Financial Responsibility for required infrastructure
33.
1) The EAPHLNP shall be responsible for the financial resources necessary for the
running of the regional laboratory Web Portal and the respective interconnectivity
systems.
34.
2) Each Partner State shall individually be responsible for the financial resources
required to establish the infrastructure necessary for its Health laboratory ICT
departments to achieve seamless interface with the Network.
PART IV
INFORMATION TO BE STORED ON THE NETWORK
6. Data sharing of Health and Laboratories databases of Partner States

35.
36. The Partner States shall interconnect their laboratories and Health
databases with the Network and shall share all information relating
to all Health, Laboratories and duties administered by their
respective health laboratories departments under their respective
jurisdictions.
37.
7. Externally sourced Information
1) A partner state may share over the Network, any information sourced from outside
the East African Community, with other Partner States.
38.
2) A Partner having obtained externally sourced information shall be responsible for the
capturing it and availing it over the Network
39.
3) Externally sourced information may include, but shall not be limited to;
a) Data from countries outside the EAPHLNP
b) Information from regulatory bodies such as the WHO

4) All externally sourced information shall first be approved by the Committee before it
can be availed for access and use by users of the Network.
40.
PART V
INFORMATION TECHNOLOGY
8. Application of Information Technology

41.
1) Partner States shall use the agreed standards when developing IT systems or
applications for their Health Laboratories operations and shall ensure that such
systems or applications will allow smooth interface with the Network.
42.
2) The Committee shall require each Partner State to have its Health Laboratories IT
System properly certified and accredited as being up to the standard set out by the
Team, before it can be connected to the Network.
43.
3) Regard shall be had to the EAPHLNP Minimum Baseline standards before any
information communication technology is connected into the Network.
44.
4) Accreditation in paragraph (2) shall be carried out by a Committee selected by the
EAPHLNP Secretariat.
45.
5) A Partner State proposing to change its Health Laboratories IT system after the
launch of the Network shall evaluate and determine the potential impact of the
proposed changes on the Network and its authorized users and shall promptly inform
the Committee before such changes are implemented.
46.
6) A Partner State proposing to change its ICT laws shall evaluate and determine the
potential impact of the proposed changes on the Network and shall inform the
Committee of such changes.
47.
7) Partner States shall employ the use of equipment and software that can adequately
handle the volume of information envisaged to be received and stored by them or
exchanged with the National Health Laboratories Database.
48.
8) With respect to paragraph (7) of this Regulation, where before or after the date of
launching the Network, it is brought to the attention of a Partner State that the
equipment it has in place is inadequate to ensure smooth interface with the Network,
then it shall be incumbent upon the Partner State notified to upgrade its Health
Laboratories system to the agreed level and Partner State shall provide the
Committee with a timeframe within which such work shall be complete.
49.
9) Partner States shall continuously develop their Health Laboratories IT systems in a
secure manner to allow for improved and efficient access to and use of information
by the authorized users from any Health Laboratories office location in the country.
50.
10) The Committee shall establish and implement processes to;
a) Assess consistency with these regulations;
b) ensure integrity and adequacy of the security management system and Identity
and access management system; and

c) Identify potential areas for improving the security management system in order to
enhance supply chain security and shall in this regard;
i) regularly undertake assessments of the security risks at least quarterly in a
year in their operations and take appropriate measures to mitigate those
risks;
ii) conduct regular self-assessments of its security management system;
iii) fully document the self-assessment procedure and those of the responsible
parties; and
iv) Include in the review assessment results, feedback from the Health
Laboratories Authorities and recommendations for possible enhancements to
be incorporated in a plan for the forthcoming period to ensure continued
adequacy of the security management system.
51.
9. Mode of Exchange of Information over the Network
52.
1) Information exchange shall be made using the methods and modalities determined
by the Committee.
53.
2) In so far as is possible, exchange of information over the Network shall be
spontaneous and seamless to allow for real time access to authorized users.
54.
3) The Committee may decide which information should not be exchanged
spontaneously.
55.
4) The Committee shall provide for instances in which and the conditions under which
paper or other transactions may be used in place of electronic exchanges of data,
taking the following into account;
56.
a) the possibility of temporary failure of the Health Laboratories authorities
computerized systems;
b) International Conventions and Agreements which provide for the use of paper
documents;
c) Users without direct access to the computerized systems and with no means of
providing electronic information;
d) Practical requirements for declarations to be made orally or by any other Act of
the EAC.
57.
10. Document Management System
58.
59. The Committee shall develop a Content Management System for
any physical documents that may have been forwarded by the
various Health Laboratories Authorities.
60.
11. Data security and integrity
61.
1) Subject to Paragraph (5) of this Regulation, no user shall have the authority to modify
information accessed over or via the National Health Laboratories Database of the
Network.
2) The Committee shall develop guidelines on classification of information for purposes
of providing levels of rights to access and use the information.
3) The Committee shall develop guidelines to the Health Laboratories Authorities of
Partner States relating to encryption of information that shall be applied to the various
classes of information. The guidelines shall be developed in line with the EAPHLNP
Security Requirements

4) All encrypted Information exchanged over the Network shall only be accessible by
those users having the required level of authorization to access it and the necessary
key to view the information.
5) Information obtained through the Network may only be modified if it contains
inaccuracies and such modification shall first be approved by the Committee in
consultation with the Partner State from whom the information originated and upon
request by the Partner State seeking to modify it. Such request shall be accompanied
by the necessary proof of the inaccuracies sought to be corrected.
6) Any modification that is necessary under paragraph (5) shall be done by the
Committee or by the Partner State from whom the information originated with the
approval of the Committee.
7) The Committee shall generate and maintain reports of;
a) All encrypted information forwarded to the National Health Laboratories Database
b) People authorized to view the encrypted information
c) Access and Use of encrypted information
d) Instances where information has been shared modified or copied.
e) Unauthorized access of encrypted information breaches in security of the system.
8) The Committee shall be responsible for the installation of the necessary antivirus
applications and software to minimize the risk of data loss resulting from malicious
programs and applications that would compromise the integrity of the information in
the National Health Laboratories Database.
62.
12. Data storage
1) All information exchanged between Health Laboratories Authorities under these
regulations shall be stored in the National Health Laboratories Database set up under
Regulation 3 (2) (a) of these regulations
2) All data stored on the National Health Laboratories Database shall be backed up by
the technical personnel as appointed by the Committee and shall be stored in the
backup facility established by the Directorate.
3) The Committee shall develop the guidelines for its staff relating to but not limited to;
a) The period of storage but any such period shall not be less than that provided for
under the Act.
b) Archival of information and access to archived information
63.
13. Back up of Information.
64.
1) The Directorate shall establish a Data Backup facility for all information on the
National Health Laboratories Database and software, application and systems on the
Network where necessary.
2) The data backup facility in paragraph (1) of this regulation shall be stationed in any of
the Approved East African Community facilities.
3) In this regulation, an Approved East African Community Facility refers to an
institution owned and operated by the EAC.
4) The Committee shall establish crisis management and recovery procedures which
must include Business Continuity planning and disaster recovery measures.
5) The Committee shall document and make available all contingency plans for
emergency security situations and for disaster recovery and shall include periodic
training of employees and testing of emergency contingency plans.
6) The Committee shall establish measures to ensure business continuity with respect
to instances set out in regulation 9 (4).
65.
14. Incident reporting
1) In order to safe guard the confidentiality, integrity and availability of the interfaced
systems of the Partner States and the data they store, process and transmit, the

Committee shall develop guidelines for incident reporting by authorized users of the
Network.
2) The guidelines in paragraph (1) shall relate to but shall not be limited to the following;
a) Security Incidents detected and the proposed security precautions.
b) Disasters and other contingencies that may disrupt the normal operation of one
or both of the connected systems.
c) Material changes to System Configuration:
d) New Interconnections by the Partner States with any other IT system, including
systems that are owned and operated by third parties.
e) Personnel Changes.
66.
15. Operational Guidelines and training of technical staff
67.
1) Every Partner State shall put in place operational guidelines in its Health
Laboratories Department to ensure that;
a) Access to the Network is secured and only made by authorized persons.
b) Authorized users in the respective Health Laboratories Department are sensitized
and properly trained to adhere to the standards relating to the form and content of
the data to be captured that has been agreed upon under regulation 9 (1).
c) Authorized users in the Health Laboratories Departments attached to the Network
are aware of and comply with the requirements relating to information security,
data protection and confidentiality rules, authorized access and integrity of data.
d) There are appropriate measures and procedures for identifying cybercrime and IT
related offences.
68.
2) Every Partner State shall designate in its Health Laboratories department properly
qualified technical officers in charge of its IT systems and shall provide the proper
and convenient contacts to facilitate direct communication between such technical
officers and the Committee to support the management and operation of the
Network.
69.
70.
PART VI
ACCESS, USE AND CONFIDENTIALITY PROVISIONS
16. Use of information:

71.
1) Any information communicated over the Network under these regulations shall be
used only for the purposes for which the Network was established.
72.
2) Notwithstanding the provisions of paragraph (1), information sourced or accessed by
a Partner State from the Network may be used for other purposes or by any other
competent authority in the territory of the Partner State including its use in criminal
investigations, prosecutions or proceedings subject to any terms and conditions that
the Partner State which provided the information may specify.
73.
3) The Committee shall keep a record of all information including personal data
exchanged between Partner States under these regulations for a period of 10 years.
74.
17. Confidentiality of information;
1) Any information communicated under these regulations shall be protected and

treated as confidential and may be disclosed only to persons or authorities
authorized, including courts and administrative bodies, in the jurisdiction of the
Partner State concerned with the assessment or the determination of appeals in
relation to taxes administered by the Health Laboratories Authority of a Partner State.
75.
2) The Communication of confidential data to the Health Laboratories authorities and
other competent authorities of countries or territories outside the Health Laboratories
territory of the East African Community shall be subject to the provisions of the EAC
Cyber laws, WHO and the provisions of any International Agreement ensuring an
adequate level of data protection.
76.
3) All Authorised Users shall keep the following obligations as to confidentiality and
integrity.
a) Safe guard the confidentiality, integrity and availability of the information
resources to which he or she or they have access.
b) Not use or disclose any electronic data, record, book, register, correspondence,
information, document or any other material sourced or obtained from the
National Health Laboratories Database to any other person for any other purpose
other than that for which he or she or they obtained access except for the
purposes of prosecution for an offence under any written law or in accordance
with an order of court.
c) Limit their access, use of information received from the National Health
Laboratories Database to the purposes for which access was granted.
d) Treat as confidential and maintain the confidentiality of all information to which
they have access privileges and shall only disclose such information to those with
the authority to receive such information.
e) Use secure electronic communications by transmitting Confidential Information
only to authorized persons or entities, in accordance with approved security
standards.
f) Take precautions to prevent the introduction into their personal computers of
software viruses, malicious or any other code that might compromise the
information security or normal operations.
77.
18. Personal data protection
78.
1) Where the information to be provided under these regulations includes personal data,
the personal data shall not be furnished to any other Partner State without the
consent of the Partner State from which it originated.
79.
2) Where personal data is required for purposes of carrying out the duties and
obligations under the Network, the originating Partner state shall ensure that data;
a) Has been processed fairly and lawfully
b) Is collected for specified, explicit and legitimate purposes and not further
processed in a way incompatible with those purposes. Further processing of data
for historical, statistical or scientific purposes shall not be considered as
incompatible provided that Partner States provide appropriate safeguards;
c) Is adequate, relevant and not excessive in relation to the purposes for which they
are collected and/or further processed;
d) Is accurate and, where necessary, kept up to date; every reasonable step must
be taken to ensure that data which are inaccurate or incomplete, having regard to
the purposes for which they were collected or for which they are further
processed, are erased or rectified;

e) Kept in a form which permits identification of data subjects for no longer than is
necessary for the purposes for which the data were collected or for which they
are further processed. Partner States shall lay down appropriate safeguards for
personal data stored for longer periods for historical, statistical or scientific use.
3) It shall be the responsibility of the Committee to ensure that the requirements of this
regulation are complied with.
80.
4) The processing of data shall be deemed legitimate if;
a) the data subject has unambiguously given his consent; or
b) processing is necessary for the performance of a contract to which the data
subject is party or in order to take steps at the request of the data subject prior to
entering into a contract; or
c) processing is necessary for compliance with a legal obligation to which the
controller is subject; or
d) processing is necessary in order to protect the vital interests of the data subject;
or
e) processing is necessary for the performance of a task carried out in the public
interest or in the exercise of official authority vested in the controller or in a third
party to whom the data are disclosed; or
f) Processing is necessary for the purposes of the legitimate interests pursued by
the Data controller to whom the data are disclosed, except where such interests
are overridden by the interests for fundamental rights and freedoms of the data
subject which require protection under International Law.
81.
5) Consent shall be unambiguous, if Data controller or its representative has provided a
data subject from whom data relating to himself or herself are collected with at least
the following information, except where he or she already has it;
a) the identity of the Data controller and of his representative, if any;
b) the purposes of the processing for which the data are intended;
c) any further information such as;
i) the categories of data concerned,
ii) the recipients or categories of recipients,
iii) the existence of the right of access to and the right to rectify the data
concerning him or her in so far as such further information is necessary,
having regard to the specific circumstances in which the data are collected, to
guarantee fair processing in respect of the data subject.
82.
6) Definitions under this regulation;
a) Processing in relation to personal information or data, means obtaining,
recording or holding the information or data or carrying out any operation or set of
operations on the information or data, including
i) Organisation, adaptation or alteration of the information or data,
ii) retrieval, consultation or use of the information or data,
iii) disclosure of the information or data by transmission, dissemination or
otherwise making available, or
iv) Alignment, combination, blocking, erasure or destruction of the information or
data.
b) Data controller means a person who (either alone or jointly or in common with
other persons) determines the purposes for which and the manner in which any
personal data are, or are to be, processed.
c) Data subject means the person to whom the personal data relates.
83.
19. Access to information
84.

1) The Committee shall establish procedures for the safety and security of the Network
for the purpose of
85.
a) preventing unauthorized access to equipment used for the processing of
information in the National Health Laboratories Database;
b) preventing unauthorized access to the Network;
c) ensuring and establishing that the Authorized users have access to the Network;
d) establishing which information is introduced into the National Health Laboratories
Database, by whom, and to monitor queries, if any;
e) preventing the unauthorized entry, reading, copying, amendment or deletion of
information from the Network during the communication of data and the
transportation of data media, or
f) Any other ICT security aspects.
86.
2) Access to information over the Network shall not be granted without the necessary
access privileges by the Committee. An identity and access management system
shall be centrally managed by the Committee for allocating passwords, user rights,
revocation of access, and related purposes for all systems associated with the
Network
87.
3) Pursuant to Regulation 19(1), all information exchanged over the Network shall be
grouped into different levels of classification according to the guidelines provided by
the Committee in Regulation 11 (2) depending on its sensitivity and each Partner
State shall provide access approval levels for each class.
88.
4) Pursuant to Regulation 19 (3), the Health Laboratories Authority of each Partner
State shall forward a list of users approved to access information on the Network and
such list shall indicate the class of information to be accessed and the level of
authorization for the user.
89.
5) Each Partner State shall provide a maximum of three persons per business process
who is authorized to access information on the Network relevant to their part of the
business processes; and shall also provide the name of one person who shall have
unlimited rights of access to information relating to all business processes.
90.
91.
6) The Committee shall also assign its own staff access rights relevant to their part of
the business processes and shall also have in place some members at the
Directorate level who shall have privileged access rights of access, to access and
provide information from the Network.
92.
7) The Committee shall, where satisfied that the users on the list advanced by the
Health Laboratories Authorities have the appropriate authorization to access
information, provide such access through Network account and password which shall
correspond with their level of authorization to access information for their relevant
business processes.
93.
8) It shall be the responsibility of the Partner State from whom the information
originates, to ensure that, where the contents of the information require it to be
encrypted under Regulation 11, such encryption has been done before the
information is exchanged.
94.
9) A Partner State forwarding encrypted information over the Network pursuant to
Regulation 11, shall specify the required level or type of personnel authorized to
access and use the information and shall provide that personnel with the necessary

key required to break the encryption so as to enable them to view or open the
information.
95.
10) The Committee shall maintain records of all unauthorized access of information over
the Network, including but not limited to;
96.
a) Identities of those who accessed information without authorization
b) IP addresses, locations
c) Dates and time
d) the user ID of the accessing User;
e) the role the User is exercising;
f) the organisation of the accessing User
g) the unique client ID;
h) the function performed by the accessing User;
i) the NHL-id of the Originator/Target;
j) a time stamp including time zone used.
k) Any other information that can help identify the offenders
97.
11) The Committee shall notify the relevant Partner States where such unauthorized
access has occurred and shall require them to take the necessary disciplinary action
and report on the remedial steps taken and where no such disciplinary action and or
remedial step is taken by the relevant Partner State, then the Partner State in
question shall provide the necessary explanations to the Team.
98.
12) The Committee shall report to the Directorate regarding any steps taken under
Regulation 19 (10) or the lack thereof and make the necessary recommendations to
the Directorate on possible actions that can be taken to protect the information on the
National Health Laboratories Database from further unauthorized access.
99.
20. Information Security Agreements
100.
1) All users, staff, technical personnel having access to the information on the National
Health Laboratories Database shall sign Information Security Agreements setting out
their obligations as to the access and use of information over the Network.
101.
2) The Committee shall not permit access to the Network by a user unless proof has
been furnished by the relevant Health Laboratories Authority of the Partner State that
the User has signed an Information Security agreement.
102.
3) Where the Health Laboratories Authority of a Partner State finds an Authorized User
to be in breach of the obligations set out the Information Security Agreement, it shall
notify the Committee of such instances and shall provide the details of breach and
remedial action to taken.
103.
4) Where the Committee is of the opinion that a breach of obligations in the Information
security agreement has occurred, it shall notify the Health Laboratories Authority of
the relevant Partner State providing details and reasons of the suspected breach.
104.
5) An Authorized user found to be in breach under Regulation 20 (3) shall be replaced
immediately unless the Relevant Health Laboratories Authority can show that the
disciplinary action taken is sufficient to correct the breach and prevent further breach
by that User.
105.

6) Where an authorized User has been replaced under Regulation 20 (5) the relevant
Partner State shall provide the necessary details required for purposes of regulation
19 (4).
106.
7) The Committee shall reserve the right to block access to the Network by an
Authorized User if it is not satisfied that the remedial action taken by the relevant
Partner State is sufficient to remedy any negative effect of the breach that occurred.
107.
8) The Committee and the respective Health Laboratories Authorities of each Partner
State shall maintain the following records;
a) A record of all agreements signed by Authorized Users of the Network.
b) A record of any remedial steps taken relating to breaches in Information Security
Agreements
c) A record of all users blocked under Regulation 20 (7) and the reasons provided.
108.
21. Obligations Of Users as to passwords
All Authorized Users shall;
a) be responsible for the confidentiality of the password provided and shall not loan
the user identification and password or share it with others, except as authorized
in writing by Team;
b) be personally accountable for all actions that occur under the user identification
provided to the Assignees and Authorized Users;
c) log out or lock the terminal when leaving it, even for a short period of time;
d) Not use the user identification provided by Committee for private use or any other
purposes other than those specifically allowed by Team;
e) Not test or attempt to compromise the Network security controls without the
specific advance approval in writing from Team.
f) Report any improper access, use or disclosure to their immediate supervisor.
PART VII: LEGAL EFFECT, AUTHENTICTY AND ADMISSIBILITY
22. Legal effect of information

The information exchanged or stored on the National Health Laboratories Database shall
not be denied legal effect, validity or enforcement solely on the ground that it is wholly or
partly in the form of a data message.
23. Authenticity of information
109.
1) Information stored on the National Health Laboratories Database shall be presumed
to have been presented or retained in its original form, if
110.
a) the integrity of the information from the time when it was first generated in its final
form as a data message or otherwise has passed assessment in terms of
paragraph (2); and
111.
b) that information is capable of being displayed or produced to the person to whom
it is to be presented.
112.
2) For the purposes of Regulation 23 (1)(a), the authenticity of information shall be
assessed

a) by considering whether the information has remained complete and unaltered,
except for the addition of an endorsement and any change which arises in the
normal course of communication, storage or display;
113.
b) in light of the purpose for which the information was generated; and,
114.
c) having regard to all other relevant circumstances.
115.
24. Admissibility and evidential weight of information kept on the Network
116.
1) Where information sourced from the National Health Laboratories Database is to be
used in legal proceedings, the rules of evidence shall not be applied so as to deny
the admissibility of that information
a) merely on the ground that it is constituted by a data message or an electronic
record;
b) if it is the best evidence that the person adducing the evidence could reasonably
be expected to obtain; or
c) Merely on the ground that it is not in its original form.
117.
2) A person seeking to introduce information or records sourced from the National
Health Laboratories Database in legal proceeding has the burden of proving its
authenticity by evidence capable of supporting a finding that the record of information
is what the person claims it to be.
118.
3) Subject to Regulation 24 (2), where the best evidence rule is applicable in respect of
information sourced from the National Health Laboratories Database, the rule is
fulfilled upon proof of the authenticity of the records system in or by which the data or
information was recorded or stored.
119.
4) When assessing the evidential weight of a data message or an electronic record
sourced from the National Health Laboratories Database, regard shall be had to
a) the reliability of the manner in which the data message was generated, stored or
communicated;
b) the reliability of the manner in which the authenticity of the data message was
maintained;
c) the manner in which the originator of the data message or electronic record was
identified; and
d) any other relevant factor.
120.
5) The authenticity of the electronic records system used by the Network to record and
store information shall, in the absence of evidence to the contrary, be presumed
where
a) there is evidence that supports a finding that at all material times the system or
other similar device was operating properly or, if it was not, the fact of its not
operating properly did not affect the integrity of the electronic record and there
are no other reasonable grounds to doubt the integrity of the system;
b) it is established that the electronic record was recorded or stored by a party to the
proceedings who is adverse in interest to the party seeking to introduce it; or
c) It is established that the information was recorded or stored in the usual and
ordinary course of business by a person who is not a party to the proceedings
and who did not record or store it under the control of the party seeking to
introduce the record.
121.
6) For the purposes of determining whether information is admissible under this
regulation, evidence may be presented in respect of set standards, procedure, usage

or practice on how information is to be recorded or stored on the Network, with
regard to the type of business or endeavors that used, recorded or stored the
information and the nature and purpose of the information.
122.
7) This regulation does not modify the common law or a statutory rule relating to the
admissibility of records, except the rules relating to authentication and best evidence.
PART VIII OFFENCES AND PENALTIES
25. Unauthorized access to or improper use of the Network

123.
A person who intentionally accesses or intercepts any
program or data on the Network without authority or permission to
do so commits an offence.
124.
1) A person who unlawfully produces, sells, offers to sell, procures for use, designs,
adapts for use, distributes or possesses any device, including a computer program or
a component which is designed primarily to overcome security measures for the
protection of data on the Network or performs any of those acts with regard to a
password, access code or any other similar kind of data, commits an offence.
125.
2) A person who utilizes any device or computer program specified in Regulation 25 (2)
in order to unlawfully overcome security measures designed to protect the program
or data on the Network or access to that program or data, commits an offence.
126.
3) A person who accesses any information system of the Network so as to constitute a
denial including a partial denial of service to authorized users commits an offence.
127.
4) The intent of a person to commit an offence under this regulation need not be
directed at
a) any particular program or data;
b) a program or data of any particular kind; or
c) A program or data held in any particular computer.
128.
5) A person who commits an offence under this regulation is liable on conviction
a) In the case of an individual, to a fine not exceeding five thousand dollars or
imprisonment not exceeding two years or both.
b) In the case of a body corporate, to a fine not exceeding twenty five thousand
dollars.
129.
6) A person shall not be liable under this regulation where he or she;
a) Is a person with a right to control the operation or use of the computer system
and exercises such right in good faith.
b) Has the express or implied consent of the person empowered to authorize him to
have such an access
c) Has reasonable grounds to believe that he had such consent as specified under
Regulation 25 (6)(b) above; or
d) Is acting in reliance of any statutory power for the purpose of obtaining
information, or taking possession of any document or other property.
130.
26. Access with intent to commit or facilitate the commission of a further offence.

1) Any person who causes a Computer system to perform any function for the purpose
of securing access to any program or data held in any computer system, with intent
to:
a) commit an offence or
b) Facilitate the commission of any other offence
under any law, shall commit an offence and shall, on conviction be liable to a fine not
exceeding twenty five thousand dollars or to imprisonment for a term not exceeding
two years or both.
2) The offence to be facilitated under regulation 26(1)(b) may be one committed by the
person referred to in regulation 26 (1) or by any other person.
131.
3) It is immaterial for the purposes of this regulation whether the act under this
regulation is committed on the same occasion as the offence under regulation 12 or
on any future occasion.
132.
4) A person who commits an offence under this regulation is liable on conviction to a
fine not exceeding Two thousand Five hundred dollar or imprisonment not exceeding
five years or both.
5) For the purposes of this regulation, it is immaterial that
a) the access referred to in regulation 26 (1) is authorized or unauthorized;
b) the further offence to which this regulation applies is committed at the same time
when the access is secured or at any other time.
133.
27. Unauthorized modification of computer data
1) A person who knowingly a) does any act which causes an unauthorized modification of the contents of any
computer operated or used the Network; and
b) has the requisite intent and the requisite knowledge at the time when he or she
does the act, commits an offence.
2) For the purposes of regulation 27 (1)(b) the requisite intent is an intent to cause a
modification of the contents of any computer operated or used by the Network and by
doing so
a) to impair the operation of any computer of the Network;
b) to prevent or hinder access to any program or data held in any computer of the
Network; or
c) to impair the operation of any such program of the Network or the reliability of any
such data.
134.
3) The intent under regulation 27 (1)(b) need not be directed at
a) any particular computer of the Network;
b) any particular program or data or a program or data of any particular kind; or
c) any particular modification or a modification of any particular kind.
135.
4) For the purposes of regulation 27 (1)(b) the requisite knowledge is knowledge that
any modification that the person intends to cause is unauthorized.
5) It is immaterial for the purposes of this regulation whether an unauthorized
modification or any intended effect of it of a kind specified in regulation 27 (2) of this
regulation, is intended to be permanent or temporary
6) A person who commits an offence under this regulation is liable on conviction, to a
fine not exceeding Five thousand dollars imprisonment not exceeding 5 years or
both.
7) Where as a result of the commission of an offence under this regulation;

a) The operation of the computer system; or,
b) Access to any program or data held in any computer; or
c) The operation of any program or the reliability of any data is suppressed,
modified or otherwise impaired,
a person convicted for the offence shall be liable on conviction to a fine not
exceeding ten thousand dollars and or imprisonment for a term not exceeding seven
years or both.
8) A person shall not be liable under this regulation where he or she is acting in reliance
of any statutory power.
136.
9) Modification is unauthorized if;
a) the person whose act causes it is not himself or herself entitled to determine
whether the modification should be made; and
b) he or she does not have consent to the modification from any person who is so
entitled.
137.
28. Unauthorized use or interception of computer service
1) Subject to regulation 28 (2), a person who by any means knowingly
a) secures access to any computer operated or used by the Network without
authority for the purpose of obtaining, directly or indirectly, any computer service;
138.
b) intercepts or causes to be intercepted without authority, directly or indirectly, any
function of a computer operated or used by the Network, by means of an electromagnetic, acoustic, mechanical or other device whether similar or not; or
139.
c) uses or causes to be used, directly or indirectly, the computer operated or used
by the Network or any other device for the purpose of committing an offence
under regulation 28 (1) (a) or (b), commits an offence and is liable on conviction
to a fine not exceeding ten thousand dollars or to imprisonment not exceeding
five years or both; and in the case of a subsequent conviction, to a fine not
exceeding Fifteen thousand dollars or imprisonment not exceeding 7years years
or both.
2) If any damage is caused as a result of an offence under this regulation, a person
convicted of the offence is liable to a fine not exceeding Fifteen thousand dollars or
imprisonment not exceeding 7years years or both.
140.
3) For the purposes of this regulation, it is immaterial that the unauthorized access or
interception is not directed at
a) any particular program or data;
b) a program or data of any kind; or
c) a program or data held in any particular computer;
141. operated or used by the Network
4) A person shall not be liable under regulation 28 (1) where he or she
a) Has express or implied consent of both the person who sent the data and the
intended recipient of such data;
b) Is acting in reliance of any statutory power
c) Is acting in reliance of any statutory power
142.
29. Unauthorized obstruction or use of computer.
A person who, knowingly and without authority or lawful excuse does any act which
directly or indirectly causes

a) a degradation, failure, interruption or obstruction of the operation of a computer
system; or
b) a denial of access to, or impairment of any program or data stored in, the computer
system;
shall commit an offence and shall, on conviction be liable to a fine not exceeding ten
thousand dollars and or imprisonment for a term not exceeding ten years or both.
30. Unauthorized disclosure of access code
143.
1) A person who knowingly and without authority discloses any password, access code
or any other means of gaining access to any program or data held in any computer
operated or used by the Network, knowing or having reason to believe that it is likely
to cause loss, damage or injury to any person or property, commits an offence.
144.
2) A person who commits an offence under regulation 30(1) is liable on conviction to a
fine not exceeding five thousand dollars or to imprisonment not exceeding five years
or both; and in the case of a subsequent conviction, to a fine not exceeding ten
thousand dollars or imprisonment not exceeding seven years or both.
31. Unauthorized disclosure of information.
Except for the purposes of provided in regulation 16 of these Regulations no one shall
disclose any information sourced from the Network and anyone who contravenes this
regulation commits an offence and is liable on conviction to a fine not exceeding five
thousand dollars or to imprisonment not exceeding five years or both.
32. Electronic fraud.
1) A person who carries out electronic fraud using a Computer or system operated or
used by the Network commits an offence and is liable on conviction to a fine not
exceeding ten thousand dollars or imprisonment not exceeding seven years or both.
145.
2) For the purposes of this Regulation electronic fraud means deception, deliberately
performed with the intention of securing an unfair or unlawful gain where part of a
communication is sent through a computer or system used or operated by the
Network or any other communication and another part through the action of the
victim of the offence or the action is performed through a computer used or operated
by the Network or both.
146.
33. Tampering with Computer Source documents
147. Any person who knowingly or intentionally conceals, destroys
or alters, or intentionally or knowingly causes another person to
conceal, destroy or alter any computer source code, computer
programme, computer system or computer network, where the
computer source code is required to be kept or maintained by law
for the time being in force, shall on conviction be liable to a fine not
exceeding five thousand dollars or to imprisonment not exceeding
five years, or both.
148.
34. Publishing of obscene information in electronic form
149. Any person who publishes or transmits or causes to be
published in electronic form, any material which is lascivious or
appeals to the prurient interest and its effect is such as to tend to
deprave and corrupt persons who are likely, having regard to all
relevant circumstances, to read, see or hear the matter contained

or embodied therein, shall on conviction be liable to a fine not
exceeding five thousand dollars or to imprisonment not exceeding
five years, or both.
150.
35. Publication for Fraudulent Purposes
151. Any person who knowingly creates, publishes or otherwise
makes available an electronic signature certificate for any
fraudulent or unlawful purpose commits an offence and shall on
conviction be liable to a fine not exceeding twenty five thousand
dollars or imprisonment for a term not exceeding five years, or
both.
152.
36. Enhanced punishment for offences involving protected computers.
1) Where access to any protected computer is obtained in the course of the commission
of an offence under regulations 25, 27, 28, 29, the person convicted of an offence is,
instead of the punishment prescribed in those sections, liable on conviction, to a fine
not exceeding fifty thousand dollars or imprisonment for a term not exceeding ten
years or both.
2) For the purposes of Regulation 36 (1), a computer is treated as a protected
computer if the person committing the offence knows or ought reasonably to have
known, that the computer or program or data is used directly in connection with or
necessary for
a) the security, defence or international relations of the East African Community;
b) the existence or identity of a confidential source of information relating to the
enforcement of a criminal law;
c) the provision of services directly related to communications infrastructure,
banking and financial services, public utilities or public key infrastructure; or
d) the protection of public safety including systems related to essential emergency
services such as police, civil defence and medical services.
3) For the purposes of any prosecution under this section, it shall be presumed, until the
contrary is proved, that the accused has the requisite knowledge referred to in
Regulation 36 (2).
153.
154.
37. Abetment and attempts.
1) A person, who abets another person in committing an offence under these
Regulations, commits that offence and is liable on conviction to the punishment
prescribed for the offence.
155.
2) Any person who attempts to commit any offence under these Regulations commits
that offence and is liable on conviction to the punishment prescribed for the offence.
156.
38. Attempt defined.
1) When a person, intending to commit an offence, begins to put his or her intention into
execution by means adapted to its fulfillment, and manifests his or her intention by
some overt act, but does not fulfill his or her intention to such an extent as to commit
the offence, he or she is deemed to attempt to commit the offence.
157.
2) It is immaterial
a) except so far as regards punishment, whether the offender does all that is
necessary on his or her part for completing the commission of the offence, or
whether the complete fulfillment of his or her intention is prevented by
circumstances independent of his or her will, or whether the offender desists of
his or her own motion from the further prosecution of his or her intention; or

b) that by reason of circumstances not known to the offender it is impossible in fact
to commit the offence.
158.
39. Cyber harassment.
A person who commits cyber harassment is liable on conviction to a fine not exceeding
Two thousand five hundred dollars or imprisonment not exceeding two years or both.
40. Offensive communication
Any person who publishes or transmits or causes to be published in electronic form, any
material which is lascivious or appeals to the prurient interest and its effect is such as to
tend to deprave and corrupt persons who are likely, having regard to all relevant
circumstances, to read, see or hear the matter contained or embodied therein, commits
an offence and shall on conviction be liable to a fine not exceeding one thousand dollars
or imprisonment for a term not exceeding one year , or both.
41. Cyber stalking
Any person who willfully, maliciously, and repeatedly uses electronic communication to
harass another person and makes a threat with the intent to place that person in
reasonable fear for his or her safety or to a member of that person's immediate family
commits the crime of cyber stalking and is liable on conviction to a fine not exceeding
two thousand five hundred dollars or imprisonment not exceeding three years or both.
42. Compensation
Where a person is convicted under these Regulations, the court may in addition to the
punishment provided therein, order such person to pay by way of compensation to the
aggrieved party, such sum as is in the opinion of the court just, having regard to the loss
suffered by the aggrieved party; and such order shall be a decree under the provisions of
the Civil Procedure law, and shall be executed in the manner provided under that law.
43. Offences by body corporate
159.
1) Where a body corporate commits an offence under these regulations, a person who
at the time of the commission of the offence is a director, manager, secretary or other
similar officer of the body corporate or was purporting to act in that capacity or was in
any manner or to any extent responsible for the management of any of the affairs of
the body corporate or was assisting in such management
a) may be charged severally or jointly in the same proceedings with the body
corporate; and
b) where the body corporate is convicted of the offence, such a person shall be
deemed to have committed an offence unless, having regard to the nature of his
or her functions in that capacity and to all circumstances, he or she proves
i) that the offence was committed without his knowledge, consent or
connivance; and,
ii) that he or she took all reasonable precautions and had exercised due
diligence to prevent the commission of the offence.
160.
2) Where a person is liable under these regulations to a punishment or penalty for any
act, omission, neglect or default, he or she is liable to the same punishment or
penalty for every such act, omission, neglect or default of any employee or agent of

his or hers, or the employee of such agent, if the act, omission, neglect or default
was committed
a) by his or her employee in the course of his or her employment;
b) by the agent when acting on his or her behalf; or
c) by the employee of such agent in the course of his or her employment by such
agent or otherwise on behalf of the agent.
161.
162. PART IX - MISCELLANEOUS PROVISIONS
163.
44. Jurisdiction
7) Where an offence under these regulations, is committed by any person in any place
outside the jurisdiction of a partner state, he or she may be dealt with as if the
offence had been committed within that Partner State.
8) For the purposes of these regulations, this paragraph applies if, for the offence in
question
a) the accused was in the Partner State at the material time; or
b) The computer or data was in the Partner State at the material time.
164.
45. Transitional provisions
The Committee shall provide guidelines for access of information over the Network
where;
a) a Partner State has not yet been connected
b) the Connection is not yet seamless
c) any other matter pertaining to the obligations of a Partner State under these
regulations
SCHEDULES
SCHEDULE 1: MINIMUM BASELINE STANDARDS

Regulation 8(3)
1.5
Detailed security requirements
The aim of this section is to describe, the EAPHLNP network minimum security
requirements.
Following the logical architecture of the EAPHLNP Health laboratories interconnectivity
network and taking care of the complexity of the project, it would seem to be useful to divide
the security requirements into three levels.
1st level - Security requirements for the EAPHLNP network as a whole (that is
environmental requirements).
2nd level - Security requirements for the National Health Laboratory (ies) (NHL) in each
partner state, starting from the observation that each National Health Laboratory must
exchange information -in a standard way- with all the others..
3rd level Minimum acceptable common security requirements for the different National
Information Infrastructure in each partner state, starting from the observation that
different levels of security requirements may have been established by the different
NHLs in each Partner state (MS).
o
Minimum because they must be the minimum that satisfies the

EAPHLNP network;
acceptable because they are already implemented or they can be easily

implemented by all partner states.
1.5.1 Security requirements for the EAPHLNP network level.

The EAPHLNP network must guarantee the security of Health Laboratories data processing.
This means that confidentiality, availability and integrity of data must be guaranteed through
suitable security requirements. More precisely, the security requirements for the EAPHLNP
network as a whole must guarantee the following items:
Identification;
Authentication;
Access control;
Non repudiation;
Data confidentiality;
Data availability;
Logging of any operation, performed by whatever User (Active Actors), which has an
impact on security.
Requirement Specification
EAPHLNPnetwork level
1.5.1.1 Identification: For each EAPHLNP laboratories interconnectivity network user
(actor) a valid and unique electronic identity must be established. The standards to
which this is unique/valid must be established by agreement.
1.5.1.2 Authentication: The identity of EAPHLNP laboratories interconnectivity network
Users (before each system access, transaction or message) must be validated.
1.5.1.3 Robustly Authenticating Users: Each MS must robustly grant the authentication of
his own Users. The conditions on which a single MS may guarantee the User
authentication, may be based on technical and/or organizational measures, These
measures, in any case, should provide that the authenticated entity must not be
repudiated.
1.5.1.4 Access control: The confidentiality and integrity of EAPHLNP laboratories
interconnectivity network information assets must be protected by preventing
unauthorised access and use (protection from both the technical and
organizational point of view).
1.5.1.5 Access control, privilege management and DHCP authorization): the authorization
with which an identified and authenticated user can get access to customer tax
information must be based on the role assigned to the user (as defined by the
Health Laboratories MS organization or authority), on the verification of the parent
Health Laboratories organization that that user is handling that specific customer
transaction.
1.5.1.6 Confidentiality: The unauthorized disclosure of personal information during the
transfer, processing and storage within EAPHLNP laboratories interconnectivity
network must be strongly prevented. The use of cryptographic mechanisms should
be adopted.
1.5.1.7 System and data integrity): the integrity of data within EAPHLNP laboratories
interconnectivity network documents, transactions or messages must be assured
for both data rest and transit.
1.5.1.8 Availability: It must be ensured that information assets are, according to the
Requirement Specification
service level agreements agreed, available in a timely and reliable manner when
needed in the scope of their professional activity by authorised EAPHLNP Users
(or actors/agents) and systems.
1.5.1.9 Non Repudiation: it must be ensured that both the User-Originator and the UserReceiver of documents and messages cannot deny their actions (documents
production, message sending, message receiving).
1.5.1.10
Accounting: it must be ensured that each activity of a User is accounted for.
In any case accounting information must not include personal data.

1.5.1.11
Auditing: it must be ensured that each action which has an impact on security
or privacy must be audited. In any case auditing information must not include
personal client data.
1.5.1.12
Fraud detection: EAPHLNP laboratories interconnectivity network should
provide tools able to discover possible frauds in the use of Health Laboratories
data.
1.5.1.13
Traceability: It must be ensured that log data can be connected from different
sources in a privacy-compliant way.

1.5.1.14
End-of-Life process: A process must be developed by each MS on when and
how to destroy all data objects created for the EAPHLNP laboratories
interconnectivity network after its conclusion
1.5.1.15
Privacy: each EAPHLNP laboratories interconnectivity network Data
Controller must guarantee the respect of the privacy obligations foreseen by its
National Law and the East Africa Community directives.
1.5.1.16
Trust: each MS should show evidences of the respect, by its own Health
Laboratories information system, of the security requirements established by the

EAPHLNP Health Laboratories agreements
1.5.2 National Health Laboratories/Revenue Authority (NHL) level.
1.5.2.1 NHL identification: a NHL must have a unique electronic identity in a common
cryptographic domain (such as, for example, digital certificates following x509
Standard).
1.5.2.2 NHL local User Identity &Access (I&A): I&A of each local User (NHL technical
staff) must be performed before he/she starts processing. The tool/mechanism
used (individually or with other security tools/mechanisms/procedures) for I&A
must prevent the Users identity (previously submitted to I&A) from being
repudiated.
1.5.2.3 Authenticating Network Access: each NHL must ensure that all connections to
remote computers and servers (for other NHLs, agents and local systems) and
applications are authenticated.
1.5.2.4 Digital Signatures: if in a MS the EAPHLNP laboratories interconnectivity network
Users apply a digital signature, then the MS-related NHL must be able to:
verify that the digital signature is valid (this implies that the user certificate is
also valid)
confirm that validity to any other MS-NHL, through a digital signature.
1.5.2.5 Digital Signatures: if a MS does not adopt a digital signature, then the MS-related
NHL must be able in any case to:
1.5.2.6 confirm to any other MS-NHLs connecting, the data integrity of the exchanged
data through a digital signature.
1.5.2.7 Access Control: a NHL must provide Access Control mechanisms which provide
functionalities that allow, for a given User, the specification of which data and
services the User can get access to, and which privileges the User has with regard
to the data and services.
1.5.2.8 Confidentiality: a NHL must use strong cryptographic mechanisms to prevent the
unauthorized disclosure of personal confidential information or security critical
system data during the transfer and processing within the NHL itself if this
processing has confidentiality vulnerabilities.
1.5.2.9 Protecting Source and Destination Integrity during data transmission): the source
and destination of the message during data transmission between NHLs in Partner
States must be protected to maintain its integrity.
1.5.2.10
Protecting Data Storage: if storage is performed, a NHL must protect
confidential information or security critical system data it contains. The use of
pseudoanonymization mechanisms should be used if possible or reasonable.
1.5.2.11
System and data integrity: a NHL must ensure, by strong cryptographic
mechanisms, the ability to discover if the Health Laboratories information has been
altered or destroyed in a unauthorized manner, so that that Health Laboratories
information may not be further processed.
1.5.2.12
Availability: NHL best effort must ensure the respect of the agreed Service
Level Agreements.
1.5.2.13
Non Repudiation: a NHL must have a strong cryptographic mechanism (e.g.
RSA) to ensure the non repudiation of each document produced by itself or
messages exchanged with other NHLs.
1.5.2.14
Accounting and Control: a NHL must have a mechanism to record every
access request and disclosure of Health Laboratories information and
transactional data, together with the time and identity of the accessing User.
1.5.2.15
Accounting records must be maintained as long as the EAPHLNP
laboratories interconnectivity network lasts, unless otherwise legally required.
1.5.2.16
Auditing: it must be ensured that each action which has an impact on security
is recorded. If data to be recorded contain both transactional and personal data,
an anonymization or pseudo-anonymization process should be used if possible or
reasonable. In any case the recorded data must not contain personal client data,
but can contain a unique identifier to a data object. Audit records must be
maintained as long as the project lasts, unless otherwise legally required.
1.5.2.17
Fraud detection: NHL must provide tools to discover possible frauds in the
use of Health Laboratories data.
1.5.2.18
Continuously Logging: logging on the NHL should be operational at all times.
In case of failure, the NHL involved must inform all the other NHLs.
1.5.2.19
Securing Access to Audit/Account Logs: a NHL must secure the access to
audit records to prevent misuse or compromise.
1.5.2.20
Logging Transactions: a secure audit record must be created each time a
User asks to access tax information of a client or to send an e-notification.
1.5.2.21
Trust: it should be allowed to submit each NHL to a second part security
audit procedure performed by the other MS, so that it will be possible to verify the
compliance with the security requirements established by the EAPHLNPPartner
States agreements.
Minimum Content of Accounting Logs): the logs should contain:

the user ID of the accessing User;
the role the User is exercising;
the organisation of the accessing User (at least in those cases where an
1.5.2.22
individual accesses information on behalf of more than one organisation);
the unique client ID;
the function performed by the accessing User;
the NHL-id of the Originator/Target;
a time stamp including time zone used.
1.5.2.23
Reporting Every Access Health Laboratories tax information, notifications
included): it should be possible to identify all requests to access to any clients
record(s) over a given period of time according to different parameters (Users,
clients records, etc)
1.5.3 Environmental and operational NHL security requirements.

It is strongly recommended that the following security requirements should be met by all NHLs engaged in the
EAPHLNPnetwork.
1.5.3.1 Personnel security security in job definition and resourcing Security
responsibilities for technical staff, data security officer and auditor should be
addressed at the recruitment stage, included in contracts, and monitored during an
individuals employment. All employees and third party users of information
processing facilities should sign a confidentiality (non-disclosure) agreement.
1.5.3.2 Personnel security user training Technical staff should be trained in security
procedures and the correct use of information processing facilities to minimize
possible security risks.
1.5.3.3 Personnel security Responding to security incidents and malfunctions Incidents
affecting security must be reported to the designated (by each MS) point of contact
through appropriate management channels as quickly as possible.
1.5.3.4 Personnel security Responding to security incidents and malfunctions All
employees and contractors must be made aware of the procedures for reporting
the different types of incident (security breach, threat, weakness or malfunction)
that might have an impact on the security of NHL assets. They must be required to
report any observed or suspected incidents as quickly as possible to the
designated (by each MS) point of contact.
1.5.3.5 Physical and Environmental security secure areas: Critical or sensitive
information processing facilities should be housed in secure areas, protected by a
defined security perimeter, with appropriate security barriers and entry controls.
They must be physically protected from unauthorized access, damage and
interference.
1.5.3.6 Physical and Environmental security secure areas: The protection provided
should be commensurate with the identified risks.
1.5.3.7 Physical and Environmental security equipment security: Equipment should be
physically protected from security threats and environmental hazards. Protection
of equipment is necessary to reduce the risk of unauthorized access to data and to
protect against loss or damage. This should also take into consideration

equipment location and disposal. Special controls may be required to protect
against hazards or unauthorized access, and to safeguard supporting facilities,
such as the electrical supply and cabling infrastructure.
1.5.3.8 Physical and Environmental security general controls: Information and
information processing facilities should be protected from disclosure, modification
or theft by unauthorized persons, and controls should be in place to minimize loss
or damage.
1.5.3.9 Communications and operations management Operational procedures and
responsibilities): Responsibilities and procedures for the management and
operation of information processing facilities must be established. This includes
the development of appropriate operating instructions and incident response
procedures.
1.5.3.10
Communications and operations management - System planning and
acceptance: The operational requirements of new systems should be established,

documented and tested prior to their acceptance and use.
1.5.3.11
Communications and operations management - Protection against malicious
software): Precautions should be required to prevent and detect the introduction of

malicious software. Software and information processing facilities are vulnerable to
the introduction of malicious software, such as computer viruses, network worms,
Trojan horses and logic bombs.
1.5.3.12
Communications and operations management - Housekeeping): Routine
procedures should be established for carrying out the agreed back-up strategy
taking back-up copies of data and rehearsing their timely restoration, logging
events and faults and, where appropriate, monitoring the equipment environment.
1.5.3.13
Communications and operations management Network management): The
security management of networks which span organizational boundaries requires

attention. Additional controls may also be required to protect critical data passing
over public networks.
1.5.3.14
Communications and operations management Media handling and
security): Media should be controlled and physically protected. Appropriate

operating procedures should be established to protect documents, computer
media (tapes, disks, and cassettes), input/output data and system documentation

from damage, theft and unauthorized access.
1.5.4 Minimum Acceptable common security requirements for the different

National Information Systems (NIS) level
The acceptable security requirements for the different National Information Infrastructure
derive from the requirements listed in the previous paragraphs and in any case- must be
compliant with the East Africa Health Laboratories Management Act.
1.5.4.1 Identity and Authorization (I&A) of a User: I&A of a User must be performed before
he/she starts processing. The tool/mechanism used (individually or with other
security tools/mechanisms/procedures) for I&A must prevent the Users identity
(previously submitted to I&A) from being repudiated.
1.5.4.2 Access Control): an Access Control tool/mechanism which enables access to
Health Laboratories information on the basis of the User Identity and the role (and
related authorizations) he/she plays, must exist.
1.5.4.3 Confidentiality and Integrity: confidentiality and integrity of the tax information
produced, sent or stored, must be guaranteed. Data should be protected by the
use of acknowledged (by the single MS) cryptographic algorithms.
1.5.4.4 Audit & Accounting: a process which allows the collection and the consultation of
the information of both the actions performed by the Users and the events which
impact on security must exist. All the data collected must be protected from
1.5.4.5 Identified Purposes: Organisations connecting to the EAPHLNP network and
organisations hosting components of the EAPHLNP laboratories interconnectivity
network must only use or disclose health and health Laboratory information for
purposes consistent with those for which it was collected, except in the case of
client consent or if permitted (or required) by law.
1.5.4.6 Segregating Network Users, Services and Systems: Organisations hosting
EAPHLNP network components must introduce network controls to segregate
information services, Users and information systems that are not involved in
access to or hosting of the EAPHLNP interconnection systems. Separated
management networks are recommended.
1.5.4.7 Privacy: each EAPHLNP laboratories interconnectivity data Controller must
guarantee the respect of the privacy obligations foreseen by its National Law.
1.5.4.8 Trust: each MS should show evidence of the respect, by its own Health
Laboratories information system, of the security requirements established by the
EAPHLNPdata exchange agreements agreement

1.5.4.9 Protecting Against Malware: each MS IT-system involved in the EAPHLNP
network must implement, according to ISO/IEC 27000, appropriate detection and
prevention controls to protect against malicious software (viruses, worms, etc).
1.5.5 Human resources security policy

Rationale
Information processed or transmitted on the EAPHLNP network ranges from public
information to Confidential information. It is necessary to confirm that personnel accessing
such information understand how to manage information and are trustworthy.
Objective
To define how:
EAPHLNPpersonnel emplyees, agents and third party users must understand their
information security responsibilities
EAPHLNPpersonnel emplyees, agents and third party users are deemed suitable for their
roles
To reduce risks of human error, theft, fraud or misuse of facilities
Security control statements

Job Descriptions Roles and responsibilities
All job roles and responsibilities must be documented and must include general as well as
specific responsibilities for implementing or maintaining security in EAC. All employees,
contractors and third party service providers of EAPHLNP must understand their job roles
and responsibilities.
Background Checks
Background checks must be performed on all personnel (including temporary personnel and
contract personnel) performing sensitive or critical job roles before they are selected for the
position or transferred to the position.
Further, personnel who are third party service
providers must have undergone a background check by their respective organizations and
the assurance of the same shall be provided to EAC. Information provided by personnel, at

the time of recruiting must be subjected to verification procedures.
Terms and Conditions of Employment

All employees, contractors and third party users of EAPHLNP partner states Information
Assets must sign and agree terms and conditions of their employment contract. These
terms and conditions shall state the organizations as well as the employees responsibilities
towards Information Security.
All employees and agents must sign and agree to the information security agreement
(Schedule III, regulation 20) before connection the EAPHLNP network is granted by the
committee.
Management Responsibilities
All supervisory roles are responsible for the performance and conduct of the staff personnel
reporting to them.
Managers or Supervisors are required to monitor performance and
conduct of each of their staff, as well as to assess their impact on the security of the
Information Assets to which the staff has access.
Confidentiality Agreements (Regulation 17)

All employees, contractors and third party users of EAPHLNP network must sign the
confidentiality agreements as an indication of their acceptance to protect the confidential and
sensitive information of the organisation. All the activities involving confidential information
will be monitored and audited periodically by the committee.
Employees, agents, contractors and third party users are required to agree and sign nondisclosure obligations (Refer to Schedule III, regulation 20, information security agreement).
Users are required not to disclose organisation information derived as a result of their
access to EACs Information Systems to unauthorized parties.

There shall be process and procedures defined for reporting the violations of confidentiality
agreements.
Appropriate disciplinary actions will be carried out against EAPHLNP
employees and agents in cases of breach of confidentiality agreements (Refer to Schedule

III, regulation 20, information security agreement).
Information Security Training and Awareness (Regulation 15)

Information Security Training and Awareness Programs must be provided to all the
employees, contractors and relevant third party users of EAPHLNP network in order to
create consciousness about the Information Security policies and processes.
Disciplinary Process
There shall be a formal disciplinary process for employees, contractors or third party users
who have violated the organizational security policies and procedures. Such a process can
act as a deterrent.
Additionally, the disciplinary process shall ensure correct and fair
treatment of employees, contractors and third party users who are suspected of having
committed serious breaches of security.
Termination of Employment
EAPHLNP must ensure that termination of employees, contractors and third party users are
done in orderly manner and responsibilities are defined within EAPHLNP to ensure the
same.
Return of Assets
All employees, contractors and third party users must return all of the organizations assets
in their possession upon termination of their employment, contract or agreement.
Removal of Access Rights

The Head of Human Resources must ensure that the access rights of all employees,
contractors and third party users to information and information processing facilities shall be

removed upon termination of their employment, contract or agreement, or adjusted upon
change of employment conditions.
1.5.5.1
Compliance with Legal requirements
Identification of applicable legislation

All relevant statutory, regulatory and contractual requirements, pertaining to EAPHLNP
business, shall be defined explicitly and documented for EAPHLNP and the use of public
health information systems. EAPHLNP shall ensure compliance to EAC Laws and Acts
relevant to its operations, wherever applicable.
These will include but not limited to
applicable laws.
Intellectual Property Rights

Procedures shall be put in place to ensure that terms and conditions and license
requirements of the copyrighted software or any other proprietary information used within
EAPHLNP are complied with.
Protection of organizational records

EAPHLNPs organizational important records relating to Information Security shall be
protected from loss, destruction and falsification, in accordance with statutory, regulatory,
contractual, and business requirements.
Data protection and privacy of personal information

Data protection and privacy shall be ensured as required in relevant legislation, regulations,
and, if applicable, contractual clauses for EAPHLN business.
Prevention of Misuse of Information Processing Facilities

Information processing facilities must be used as per policies detailed in the Information
Security Policy and User Policies and guidelines. Disciplinary action may be taken for any

wilful violation to the policies.
Regulation of cryptographic controls

Cryptographic controls, wherever applicable, shall be used in compliance with all relevant
agreements, laws, and regulations.
1.5.5.2
Compliance with Security Policies and Standards and Technical Compliance
Managers and supervisors shall ensure that all security procedures within their area of
responsibility are carried out correctly to achieve compliance with security policies and
standards.
Independent Technical Compliance Review & Reporting

Information processing resources and associated documentation must be reviewed
immediately after installation and thereafter on a quarterly basis to verify that they are
compliant with the security policies and standards. Findings and recommendations in the
report shall be communicated to the concerned department personnel for implementation.
EAPHLNP information processing resources shall be reviewed by an independent third-party

at least on an annual basis. The findings shall be reported to the committee (Refer to
Security Verification audit procedures).
SCHEDULE 3:
INFORMATION SECURITY AGREEMENT

Regulation 20
The information security agreement referred to under Regulation 20 shall be in the format
below
EAST AFRICAN COMMUNITY
East Africa Public Health Laboratory Network Project
INFORMATION SECURITY AGREEMENT
Compliance with the contents herein is mandatory:

This acknowledgement is to certify that I have read and understand the guidelines set forth
within the EAPHLNPs information security regulation and information security policy.

As (indicate whichever is applicable);
1. An employee of EAPHLNP ,
2. An employer of the Ministry of Health of the Partner State ,
I will comply with the policy and regulations referred to in this Agreement. I understand that
these guidelines may be modified by EAPHLNP at any time and that I will be advised of such
modifications as far in advance as reasonably possible.
EAPHLNP may temporarily suspend or permanently block access to the network services
and resources, prior to the initiation or completion of an investigation, when it reasonably
appears necessary to do so in order to protect the integrity, security, or functionality of the
EAPHLNP network or other computing resources or to protect the EAPHLNP from liability
I realize privacy is not guaranteed on the EAPHLNP connectivity network, and any
transmission is subject to review. My use of the EAPHLNP provided network services will
constitute acceptance of the information security policy and regulation, and consent to
monitoring while using the EAPHLNP network services.
I understand that I am personally liable for my misuse of EAPHLNP network provided by
EAPHLNP. I also understand failure to adhere to this policy and regulation may result in
disciplinary action up to and including termination of my employment and or services by my
employer. I also understand that failure to comply with the policy and regulations referred to
herein may result in criminal prosecution in the courts of law
By signing this Agreement, I understand and agree to abide by the conditions imposed
above
Name:
_________________________________
Department: __________________________________
Job Title:
___________________________________
Signature:
_______________________________
Date:
__________________________
Copy provided on (date) _______________________
By (Supervisor) _________________________________
The relevant supervisor or supervising authority shall send a copy of a signed ISA to the
Committee as provided for in the regulations.

Policies &amp; Procedures

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Policies &amp; Procedures

Hochgeladen von

Copyright:

Verfügbare Formate

East Africa Public Health Laboratory

Visit us on: http://eaphln-ecsahc.org/

EAPHLN/ICT/02/01 - ICT Standard Operating Guidelines and Procedures Manual

John Baptist Mugisha

2 | East Africa Public Health Laboratory Network Project

EAPHLN/ICT/02/01 - ICT Standard Operating Guidelines and Procedures Manual

ORGANISATION/ICT/02/01/02 - INTRODUCTION .................................................................................. 12

ORGANISATION/ICT/02/01/02 - ELIGIBILITY FOR ICT RESOURCES AND SERVICES .................................. 15

ORGANISATION/ICT/02/01/03 - ICT RESPONSIBLE USE ......................................................................... 17

ORGANISATION/ICT/02/01/04 - ICT STANDARDS .................................................................................. 18

ORGANISATION/ICT/02/01/05 - STAFF AWARENESS AND COMMITMENT ............................................ 20

ORGANISATION/ICT/02/01/06 - USER ACCOUNT MANAGEMENT ......................................................... 21

ORGANISATION/ICT/02/01/07 ICT ASSESSMENTS (ICT AUDITS AND INSPECTION .............................. 23

ORGANISATION/ICT/02/01/08 - NETWORK CONFIGURATION ............................................................... 28

ORGANISATION/ICT/02/01/09 - SUPPORT AND MAINTENANCE ........................................................... 30

ORGANISATION/ICT/02/01/10 - HARDWARE ........................................................................................ 35

ORGANISATION/ICT/02/01/11 - SERVICE LEVEL MANAGEMENT (PROCUREMENT) ............................... 40

ORGANISATION/ICT/02/01/12 - EMAIL ................................................................................................. 42

ORGANISATION/ICT/02/01/13 - INTERNET USAGE ................................................................................ 47

ORGANISATION/ICT/02/01/14 - ANTI-VIRUS ......................................................................................... 51

ORGANISATION/ICT/02/01/15 BACK- UP ........................................................................................... 54

ORGANISATION/ICT/02/01/16 - ICT SYSTEM ACCESS CONTROL ............................................................ 60

ORGANISATION/ICT/02/01/17 - REMOVABLE MEDIA............................................................................ 65

ORGANISATION/ICT/02/01/18 - NETWORK ACCESS .............................................................................. 67

ORGANISATION/ICT/02/01/19 - THIRD PARTY NETWORK ACCESS ........................................................ 74

ORGANISATION/ICT/02/01/20 - PASSWORD ......................................................................................... 80

ORGANISATION/ICT/02/01/21 - PHYSICAL SECURITY AND ENVIRONMENTAL CONTROLS ..................... 88

ORGANISATION/ICT/02/01/22 - CHANGE MANAGEMENT ................................................................... 101

ORGANISATION/ICT/02/01/23 - SECURITY MONITORING ................................................................... 110

ORGANISATION/ICT/02/01/24 - GENERAL SOFTWARE GUIDELINE ...................................................... 117

ORGANISATION/ICT/02/01/25 - ICT QUALITY MANAGEMENT............................................................. 124

ORGANISATION/ICT/02/01/26 - INCIDENT MANAGEMENT ................................................................. 129

ORGANISATION/ICT/02/01/27 - CONTINGENCY PLANNING ................................................................ 137

ORGANISATION/ICT/02/01/28 - IT GOVERNANCE ............................................................................... 141

ORGANISATION/ICT/02/01/29 - IT STEERING COMMITTEE.................................................................. 147

ORGANISATION/ICT/02/01/30 - ICT PROCEDURES MANAGEMENT ..................................................... 149

ORGANISATION/ICT/02/01/31 - ICT PROJECT MANAGEMENT ............................................................. 151

ORGANISATION/ICT/02/01/32 ICT PROJECT CONCEPTUALIZATION AND APPROVAL ........................ 155

ORGANISATION/ICT/02/01/33 ICT PROJECT PLANNING ................................................................... 157

3 | East Africa Public Health Laboratory Network Project

EAPHLN/ICT/02/01 - ICT Standard Operating Guidelines and Procedures Manual

ORGANISATION/ICT/02/01/34 PROJECT IMPLEMENTATION MONITORING ...................................... 161

35 ORGANISATION/ICT/02/01/35 PROJECT CLOSURE, SIGN-OFF AND RETENTION OF PROJECT

ORGANISATION/ICT/02/01/36 PROJECT DOCUMENTATION AND RETENTION .................................. 168

ORGANISATION/ICT/02/01/37 QUALITY ASSURANCE AT ACQUISITION ............................................ 170

ORGANISATION/ICT/02/01/38 QUALITY ASSURANCE AT INSTALLATION/IMPLEMENTATION ........... 174

ORGANISATION/ICT/02/01/39 RESEARCH & DEVELOPMENT ............................................................ 177

ORGANISATION/ICT/02/01/40 TRAINING ......................................................................................... 181

ORGANISATION/ICT/02/01/41 WEB APPLICATION DEVELOPMENT, HOSTING AND CONTENT ............ 184

ANNEXES ............................................................................................................................................. 187

43 ORGANISATION/ICT/02/01/ANNEX 1 - CONTINGENCY PLAN FOR LABORATORY INFORMATION

ORGANISATION/ICT/02/01/ANNEX 2- SOFTWARE BUSINESS CASE VALIDATION................................. 202

ORGANISATION/ICT/02/01/ANNEX 3 - SOFTWARE REQUIREMENTS DEFINITION ................................ 206

ORGANISATION/ICT/02/01/ANNEX 4 - SOFTWARE SECURITY REQUIREMENTS DEFINITION ................ 209

ORGANISATION/ICT/02/01/ANNEX 5 - SOLUTION DESIGN .................................................................. 222

ORGANISATION/ICT/02/01/ANNEX 6 - DEVELOPMENT & CUSTOMISATION........................................ 226

ORGANISATION/ICT/02/01/ANNEX 7 - SEPARATION OF DEVELOPMENT AND OPERATIONAL FACILITIES

ORGANISATION/ICT/02/01/ANNEX 8 - SYSTEM ACCEPTANCE TESTING ............................................... 234

ORGANISATION/ICT/02/01/ANNEX 9 - CONTINGENCY PLANNING ...................................................... 237

ORGANISATION/ICT/02/01/ANNEX 10 - SECURITY INCIDENTS ............................................................ 244

53 ORGANISATION/ICT/02/01/ANNEX 11 - INCIDENT LOGGING / IDENTIFICATION AND PROTECTING

ORGANISATION/ICT/02/01/ANNEX 12 - CONTAINMENT OF INCIDENTS .............................................. 249

ORGANISATION/ICT/02/01/ANNEX 13 - ESCALATION OF INCIDENTS TO DISASTER MANAGEMENT .... 254

ORGANISATION/ICT/02/01/ANNEX 14 - ERADICATION OF INCIDENTS ................................................ 257

Policies & Procedures

Policies & Procedures