Systems & Applications Standard

Systems and Applications Standard
First Edition 2016
The ICT Authority is a State Corporation under the State Corporations Act 446
www.ICTA.go.ke
©ICTA 2016 All rights

1 Infrastructure ICTA-2.001:2016 Provides compliant requirements for design,
Network installations and management of all categories
Standard of IT Networks to be deployed in government.
ICTA-2.001:2016 Provides compliant requirements for design,
Data Center installations and management of government
data centers.
ICTA-2.001:2016 Provides compliant requirements for design,
Cloud Computing installations and management of cloud
Standard computing infrastructures for government.
ICTA-2.001:2016 Provides the minimum specifications for all
computing devices being deployed in
End-User Equipment government.
Standard
2 Systems & ICTA-6.001:2016 Provides compliant requirements for design,
Applications Systems & installations and management of all
Applications Standard government Software and applications
3 IT Security ICTA-3.001:2016 Provides compliant requirements for design,
Information installations and management of Information
Security Standard Technology Security in government.
4 Electronic ICTA-4.001: 2016
records Electronic records Provides compliant requirements for
management and Data management of government electronic records
Management and data.
Standard
5 IT ICTA. 5.001: 2016 IT Provides compliant requirements for IT
Governance Governance Governance in government. This includes
Standard compliance requirements for government IT
service providers and Professional Staff.
6 ICT Human ICTA.7.001:2016 Provides compliant requirements for
ICT Human Capital
Capacity and Work force development of Human Capital capacity for
Development deployment and support
Standard
for government ICT infrastructure and services.
www.icta.go.ke
In order to keep abreast of progress in industry, ICTA Standards shall be regularly reviewed.
Suggestions for improvements to published standards, addressed to the Chief Executive Officer, ICT
Authority, are welcome.
©ICT Authority 2016
Copyright. Users are reminded that by virtue of Section 25 of the Copyright Act, Cap. 12 of 2001 of
the Laws of Kenya, copyright subsists in all ICTA Standards and except as provided under Section 26
of this Act, no Standard produced by ICTA may be reproduced, stored in a retrieval system in any form
or transmitted by any means without prior permission in writing from the Chief Executive Officer.
www.icta.go.ke
DOCUMENT CONTROL
Document Name: Systems and Applications Standard

Prepared by: ICTA Systems and Applications Committee
Edition: First Edition
Approved by: Board of Directors
Date App
r roved: th
11 August 2016
Effective Date: 1st January 2017
Next Review Date: After 3 years
www.icta.go.ke
Contents
FOREWORD..............................................................................................................1
1. Introduction...........................................................................................................2
2. Scope.....................................................................................................................2
3. Application............................................................................................................2
4. Normative references...........................................................................................3
5. Definitions.............................................................................................................4
6. Abbreviations........................................................................................................6
7. Services to be covered......................................................................................6
8. Sub- domains.......................................................................................................6
8.1 Architectural model for e-government applications...........................................................................................................6
8.2 Software acquisition, maintenance and disposal.................................................................................................................7
8.3 Messaging and Collaboration..............................................................................................................................................7
8.4 Websites...............................................................................................................................................................................7
9 Requirements.........................................................................................................7
9.1 Architectural model for e-government applications ...........................................................................................................7
9.2 Software acquisition, maintenance and disposal...............................................................................................................13
9.3 Messaging and Collaboration............................................................................................................................................14
9.4 Websites development management..................................................................................................................................14
ANNEXES................................................................................................................16
Annex A.1 Enterprise viewpoint: fundamentals of e-government..........................................................................................16
Annex A.2 Information viewpoint:..........................................................................................................................................23
Annex A.3 Computational viewpoint......................................................................................................................................23
Annex A.4 Engineering viewpoint: reference infrastructure...................................................................................................31
Annex B.2: Procedure for Selecting Whether to Develop or Acquire.....................................................................................35
Annex B.3 Maintenance...........................................................................................................................................................48
Annex B.4: Disposal................................................................................................................................................................52
Annex C.1: Email and Instant Messaging Policy....................................................................................................................56
Annex C.2: Video and Audio conferencing Policy.................................................................................................................64
Annex C.3: Social Media Use Policy......................................................................................................................................66
Annex C.4: Collaboration tools...............................................................................................................................................69
Annex D.1: Web Governance..................................................................................................................................................70
Annex D.2: Domain Management...........................................................................................................................................72
Annex D.3: Web Design, Inter- operability, Accessibility, Usability..........................................................................................74
AnnexD.4: Web Branding.......................................................................................................................................................76
Annex D.5: Web Content.........................................................................................................................................................80
Annex D.6: Hosting.................................................................................................................................................................82
Annex D.7: Monitoring and Evaluation...................................................................................................................................83
APPENDICES.........................................................................................................84
Appendix 1: Compliance Checklist.........................................................................................................................................84
Appendix 2: SDLC Phases....................................................................................................................................................102
Appendix 3: SDLC Activities and Outputs...........................................................................................................................103
Appendix 4: Mandatory Functionalities for System Testing.................................................................................................107
Appendix 5: Recommended Software.......................................................................................................................................109
Appendix 6: Email etiquette............................................................................................................................................116
Appendix 7: Critical Systems in Government.......................................................................................................................118
Appendix 8: Audit for Outsourced Development......................................................................................................................120
FOREWORD
The ICT Authority has express mandate to, among others, set and enforce ICT standards and
guidelines across all aspects of information and communication technology including systems,
infrastructure, processes, human resources and technology for the public service. The overall
purpose of this specific mandate is to ensure coherence and unified approach to acquisition,
deployment, management and operation of ICTs across the public service, including state agencies,
in order to promote service integration, adaptability and cost savings through economies of scales
in ICT investments.
In pursuit of achievement of this mandate, the Authority established a Standards Committee to

identify the critical standards domain areas as well as oversee the standards development process.
A total of Nine Standards falling under six different domain areas were identified by the committee
to be relevant for government ICT Standards. The development of all the identified standards was
done through a process which took into consideration international requirements, government
requirements, stakeholder participation as well as industry/sector best practices. In order to
conform to the format of other existing national standards, the committee adopted the Kenya
Bureau of Standards (KEBS) format and procedure for standards development. In addition, through
Memoranda of Understanding, KEBS has made invaluable contribution to the development of
ICTAuthority standards.
The ICTA Systems and Applications Standard, which falls under the overall Government
Enterprise Architecture (GEA), has therefore been prepared in accordance with KEBS
standards development guidelines.
The Authority has the oversight role and responsibility for management and enforcement of this
standard. The review and approval of the standard is done by the ICTA Board upon recommendation
of Standard Review Board. The Authority shall be carrying out quarterly audits in all the Ministries,
Counties, and Agencies (MCA) to determine their compliance to this Standard.
The Authority will issue a certificate of compliance to agency upon completion of the audit
assessment. For non-compliant agencies, a report detailing the extent of the deviation and the
prevailing circumstances shall be tabled before the Standards Review Board who will advise on
action to take. All government agencies are required to ensure full compliance to this standard
for effective and efficient service delivery to the citizen. The compliance period is six months from
the effective date.
www.icta.go.ke
1. Introduction
Software is a set of programs, procedures, algorithms and documentation that instruct the
computer how to carry out specified functions. Software is the organization supporting
infrastructure. It covers all the non-physical or operational components, which are required
to ensure computer's performance, primarily computer programs, data files, settings and
documentation.
An application is a type of software that allows you to perform specific tasks. Applications for
desktop or laptop computers are sometimes called desktop applications, and those for mobile
devices are called mobile apps. When you open an application, it runs inside the operating
system until you close it.
Public sector's institutions generally conduct procurement process in order to get the needed
software and applications. Software and application standard shall aim to assure software
quality, ensure software internal usability, and help evaluate the software product. Their
application by the MCAs aims at achieving the following objectives:
● Ensure data/ information sharing across Government

● Enhance user satisfaction
● Ensure compatibility
● Enhance unified support and management
● Reduce cost and improve savings
● Offer a unified training for programmers
● Improve staff productivity and
● Ensure coherence in upgrade management
2. Scope
This ICTA Standard establishes guidelines for the successful acquisition, deployment and
utilization of software systems and applications.
3. Application
This standard applies to:
● Central Government of Kenya
● County Governments
● Constitutional Commissions
● State Corporations
www.icta.go.ke
4. Normative references
The following standards contain provisions which, through reference in this text, constitute
provisions of
this standard. All standards are subject to revision and, since any reference to a standard is
deemed to
be a reference to the latest edition of that standard, parts to agreements based on this
standard are
encouraged to take steps to ensure the use of the most recent editions of the standards
indicated
below. Information on currently valid national and international standards can be obtained
from Kenya Bureau of Standards.
● I SO/IEC 12207 Software lifecycle processes

● COBIT 5: Control Objectives For Information Technology
● ISO 90003: Software engineering Guidelines
● COBIT 4: Control Objectives For Information Technology
● ISO_IEC_27002_2005: Code of practice for information security management
● ISO/IEC 26514:2008: Systems and software engineering -- Requirements for
designers and
developers of user documentation
● ISO/DIS 15489-1: Information and documentation –Records management- Part 1 General
● 15489-1: 2001: Information and documentation –Records management- Part 1 General
● ISO/NP TR 15489-2: Information and documentation –Records management- Part 2

Guidelines
● ISO/TR 15489-2: 2001: Information and documentation –Records management-

Part 2
Guidelines
● ISO 16175-1:201/2011:formation and documentation -- Principles and functional

requirements
for records in electronic office environments
● NIST Special Publication 800-45 Version 2

● National Information System Security Glossary, NSTISSI No.4009, January 1991
● ISB Standard Version 2.0
● E-mail Address naming Standard
● ISF 2011 Standard of Good Practice for Information Security
www.icta.go.ke
5. Definitions
For the purposes of this Kenya Standard the following definitions apply:
● Digital asset s any form of content and/or media that have been formatted
into a binary source which include the right to use it. A Digital file without the right to use
it is not an asset.
● system software (systems software) is computer software designed to
operate and control the computer hardware and to provide a platform for running
application software. System software an be separated into two different categories,
operating systems and utility software.
● Applications software also called end-user programs include such
things as database programs, word processors, Web browsers and spreadsheets.
● Is :the software used for computer programming,
documenting, testing, and bug fixing involved in creating and maintaining applications and
frameworks involved in a software release life cycle and resulting in a software product.
● Is computer software with its source ode made available with a
license in which the copyright holder provides the rights to study, change, and distribute
the software o anyone and for any purpose.
● Computer programs, procedures, rules, and associated documentation and
data pertaining to the operation of a computer system.
● A programmable machine that receives input, sores and
manipulates data/information, and provides output in a useful format.
● The security goal that generates the requirement for protection from
intentional or accidental attempts to perform unauthorized data reads. Confidentiality
covers data in storage, during processing, and while in transit.
● Groups of information that represents the qualitative or quantitative attributes of a
variable or set of variables. Data are often viewed as the lowest level of abstraction from
which information and knowledge are derived.
● The property that data has not been altered in an unauthorized manner.
Data integrity covers data in storage, during processing, and while in transit.
● Messages, usually text, sent from one person to another via electronic medium. Email
may also be sent automatically to a large number of addresses (mailing list).
● A structured set of activities designed to accomplish a specific objective
● A Governments physical or virtual entities (human or otherwise) that are of
limited availability and can be used to undertake operations or business change.
www.icta.go.ke
● Software Development Lifecycle - A structure imposed on the development of a
software product. The SDLC is a systematic approach to the creation of software or
application. This cycle typically includes a requirements, analysis, design, coding, test,
implementation and post- implementation phases.
● The collection of computer programs and related data that provide the instructions
telling a computer what to do.
● Maintains the systems environment of the website by identifying
system requirements selects, installs and configures server hardware, software and
operating systems, installs upgrades , defines system and operational policies and
procedures, assesses access information and security requirements and monitors system
performance.
● Responsible for the design, layout and coding of a website.
Involved with the technical and graphic design aspects of a website –how the site works
and how it looks. They may also be involved with the maintenance and update of an existing
site. A person who deals only with the graphical and appearance elements would be a web
designer, while the one w focuses on coding is a web developer. These roles are often
combined.
● A web content manager updates websites, blogs and other sites
that require regular update. The person is responsible for editing, posting and removing
content fro the site. The person may or may not be responsible for producing the actual
content.
● Small companies sometimes employ a webmaster who is responsible for all
the job roles described above. A webmaster is also sometimes the role given to a senior
person to establish the overall corporate Web design and policies, arrange all the necessary
technical resources, and supervise the design of the corporate website.
● (XHTML) is part of the family of XML markup
languages. It mirrors or extends versions of the widely used Hypertext Markup Language
(HTML), the language in which Web pages are formulated.
www.icta.go.ke
6. Abbreviations
DLC Software Development Lifecycle

MCDA Ministries, Counties, Department and Agencies
CMM Capability Maturity Model
CD-ROM Compact Disc Drive
IM Instant Messaging
NIST National Institute of Standards and Technology
COBIT Control Objectives For Information Technology
HTML Hypertext Markup Language
XHTML Extensible Hypertext Markup Language
XML Extensible markup language
CSS Cascading style sheets
SEO Search Engine Optimization
MCA Ministries Counties and Agencies
G2C Government to Citizen
G2B Government to Business
G2G Government to Government
CMS Content Management System
ICT Information Communication Technologies
COTS Commercial off the shelf software
7. Services to be covered
The document defines three target groups for the Government services
a. Government to Citizens (G2C): services which the government offers its citizens
directly
b. Government to Business (G2B): services which the government offers to
companies
c. Government to Government (G2G): government services for public agencies.
8. Sub- domains
8.1 Architectural model for e-government applications
● The enterprise viewpoint
www.icta.go.ke
● The information viewpoint
● The computational viewpoint
● The engineering viewpoint
● The technology viewpoint
8.2 Software acquisition, maintenance and disposal
- Application and system software acquisition

- Application and system software
development
- Application and system software
Maintenance
- Application and system software Disposal
8.3 Messaging and Collaboration

- E-mail and instant messaging policy
- Video and audio conferencing policy
- Social media use policy
8.4 Websites
- Web Governance
- Domain management
- Web design
- Web branding
- Web Hosting
- Web Content
- Monitoring & Evaluation
9 Requirements
9.1 Architectural model for e-government applications
The aims of the architecture model are:

a. In order to facilitate communications, a common understanding of up-to-
date IT architectures, IT technologies and e-government structures is to be
achieved.
b. Technologies available for e-government applications are to be identified, com-
pared, evaluated with regard to their relevance, and given a uniform and consistent
structure using this model.
www.icta.go.ke
c. The aim is to provide uniform standards that can be used when it comes to
implementing e- government projects. ICTA has adopted the Reference Model of Open
Distributed Processing (RM-ODP) as the approach for describing complex, distributed
e-government applications. The analysis of the application is broken down into different
viewpoints in order to reduce the complexity of the overall architecture.
www.icta.go.ke 8
This makes the demanding system easier to understand and hence better to handle.
Object orientation promotes clear-cut structures, re-usability and updating capability of
the models, components and systems created.
Enterprise
Viewpoint
Information Computational
Process models
Viewpoint Viewpoint
and roles
E-government
Data and Modules and
data modeling interfaces
Hardware
and Standards and
infrastructure techniques
Engineering Technology
Viewpoint Viewpoint
8 The ICT Authority is a State Corporation under the State Corporations Act 446
www.icta.go.ke
a. The enterprise viewpoint specifies purposes, scope, processes and policies for an
application.
b. The information viewpoint describes the characteristics and semantics of the data to
be processed, i.e. the data model.
c. The computational viewpoint represents the decomposition of an application into
functional modules and their interaction interfaces.
d. The engineering viewpoint represents the distribution of the individual elements of the
system to physical resources and their connections.
e. The technology viewpoint describes the technologies used to implement the system.
The five viewpoints can be used both to describe existing systems and to model new systems
and applications. This viewpoints on the can be used as a basis for developing concrete
models for individual e-government applications.
The enterprise viewpoint for e-government applications Annex A.1

includes two fundamental elements: the organizational
structure of e-government in general as well as the
organizational models of the application.
This is where the overall environment for the system
and its purpose are described.
Furthermore, the requirements for the system, relevant
constraints, executable actions and data processing
policies are defined from the organization's or
enterprise's point of view.
This exercise includes a definition of the procedures,
their rules, as well as the actors and their roles in the
process.
The efficiency of information technology is strongly
dependent on an integrated view. This means that first
and foremost the technical application is regarded and
described as a process rather than placing information
technology into the foreground.
Services can and should be described in the form of
technical process models. This means that all the work
steps from the beginning to the end, i.e. from the inquiry
by the customer
www.icta.go.ke
(citizen, business, other public agency, etc.) to the Annex A.1
rendering of the service, should be considered. On a
first development stage, these process models should
be left at a relatively abstract level.
New proposals of process definitions should always be
checked with a view to
a. re-usability
b. simplicity and
c. the possibility to be described by existing process
definitions.
The Application department in ICTA in charge of

Applications should offer support in this respect.
This viewpoint determines the structure and semantics Annex A.2

of the system's information. Further items include the
definition of information sources (senders) and sinks
(recipients), as well as processing and transformation
of information by the system. Integrity rules and
invariants must be additionally described.
A coherent process definition calls for the use of general

data definitions for major data identities (such the
application) and for the data to be exchanged between
processes or applications.
Data models should always be checked with a view to
reusability, simplicity and the possibility to be described
by existing data definitions.
www.icta.go.ke
Computational a. With this viewpoint a system is broken down into logic, Annex A.3
viewpoint
functional components which are suitable for
distribution. The result is objects with interfaces at
which they offer and/or use services. An e-
government application is generally divided into four
tiers (refer to Figure 3):
b. The client tier represents different access channels
reflecting different users, devices, transmission
routes, as well as different applications in order to
interact with the special applications. The terminal
devices referred to are:
● Web access via web browsers or special browser
plug-ins
● Mobile phones and personal digital assistants
(PDAs)
● External systems (such as ERP systems of
industrial companies)
c. The presentation describes the processing of
information for the client and the user's interaction
with the special application. The presentation
component includes all the standards for
communication with the relevant terminal devices of
the client tier.
d. The middle tier includes, in particular, new
developments for e-government and in most cases
constitutes the core of e-government-specific
applications. The specific business logics of the
special applications are linked together in the middle
tier. The presentation of the technical components
focuses on the description and discussion of
standards for the middle tier and its interfaces
because this is where the highest integration demand
is expected within the scope of e- government
solutions. The middle tier processes the data from
the persistence tier.
e. The persistence tier ensures the storage of data. This
is typically accomplished using databases.
The ICT Authority is a State Corporation under the State Corporations

Act 446 www.icta.go.ke
The back-end as a collective term represents
functionalities of the operating system, specific
databases as well as existing, legacy or ERP
legacy or ERP systems.
f. Within these tiers, a special application is divided
into modules which interact via defined interfaces.
Interaction takes place in the form of local and
remote communication between the modules.
The engineering viewpoint describes the system support Annex A.4

needed to permit the distribution of objects from the
computational viewpoint. This includes units where
objects are executed, such as computers and
communication infrastructures, as well as all kinds of
software platforms for distributed systems.
This viewpoint describes the concrete technologies Annex A.5

selected for implementing the system.
www.icta.go.ke
9.2 Software acquisition, maintenance and disposal
This covers developing (or purchasing and installing) and maintaining computer
applications in the whole of Government. The degree to which the responsibility for
development, implementation and maintenance of systems is centralized in a single
administrative ICT department versus decentralized and handled by the functional offices
varies from organization to organization. While these standards will sometimes refer
to the “ICT department”, these standards apply to any department or any vendor engaged
by the MCDAs that undertakes development, installation or maintenance of ICT
applications. The determination for when these standards apply depends on the nature
of the application, not on who is responsible for the development.
Application software, systems software and application Annex B.1

development software shall be acquired in consideration
of information sharing, user satisfaction, compatibility,
unified support, cost saving and improved staff
productivity. The MCDA will be required to determine
whether to develop internally or externally, do
prototyping or vendor packages
Procedure for Selecting Whether to Develop or Acquire Annex B.2
the application/system software
Application software, systems software and Annex B.3

application development software shall be
maintained to ensure availability of service
Application software, systems software and application Annex B.4

development software shall be disposed at the end of
life in consideration of information security
www.icta.go.ke
9.3 Messaging and Collaboration
MCAs shall acquire and ensure appropriate use and Annex C.1
management of E-mail and Instant messaging
applications
MCAs shall ensure appropriate acquisition, Annex C.2

management and use of video and audio conferencing
applications
MCAs shall ensure appropriate use and management Annex C.3

of social media applications
MCAs shall ensure appropriate use and management Annex C.4

of devices brought by users to the organization
9.4 Websites development management
MCAs shall establish a governance structure to Annex D.1
manage websites
MCAs shall ensure Internet domains are administered Annex D.2
to ensure consistency with the dignity and high quality
of the Government of Kenya
MCAs shall ensure websites are designed with Annex D.3
consistent layout, usability, inter-operability
MCAs shall ensure that websites and portals display in Annex D.5
a manner that is consistent with the dignity and
authority of the Government of Kenya and which is
attractive and Government-branded so that it is easily
recognizable and usable by citizens
The ICT Authority is a State Corporation under the State

Corporations Act 446 www.icta.go.ke
MCAs shall host websites securely and ensure the website are Annex D.6
updated to mitigate any cyber security threat.
MCAs shall develop content in a way that will keep Annex D.7
stakeholders interested in the site.
MCAs shall monitor and evaluate websites to ensure their Annex D.8
availability
www.icta.go.ke
ANNEXES
Annex A.1 Enterprise viewpoint: fundamentals of e-government
Certain organizational requirements must be fulfilled

in order to ensure the sustainable introduction of
e-government. The most important of these
requirements are described in the following sections.
What is generally needed is co-operation, networking

and co-ordination within and between administrative
level.
As far as administrative procedures are concerned,

insular and go-it-alone solutions must be avoided
when new applications are introduced. New solutions
must be co- ordinated between the different levels in
order to achieve maximum service depth and width
on the largest national scale possible and in order to
ensure the compatibility of administrative levels.
In order to enable the nation-wide approach cabinet

issued a circular of October 2015 where all agencies
are required to work with ICTA on issues of
e-government applications to avoid duplication and
encourage reusability. At the same time, e-
government co-ordination is to be improved and the
transfer of solutions is to be speeded up. This avoids
parallel development, saves costs and integrates,
modernizes and optimizes administrative processes.
The successful introduction and implementation of e-

governments calls for preparatory restructuring
activities on a process level. Existing rules, processes
and structures must be adapted and improved because
electronic forms of rendering services would
otherwise stumble into the same fundamental
problems which are also en- countered in conventional
workflows not based on information technology.
www.icta.go.ke
Existing administrative processes are partly the result
of historical developments and have become extremely
complex during the course of years as a result of many
small changes. The following measures are hence
recommended before special and technical
applications are implemented.
a. Simplification of processes and procedures
b. Deregulation
c. Shortening of process chains
d. Reducing interfaces
e. Avoiding iteration
f. Reducing cycle and dead times 24
This initiative is determined to achieve the fastest
possible simplification of processes and statutory
provisions concerning frequently used services involving
multiple administrative levels.
The use and updating of standards means a continuous

exchange of information and training process. Training
people in the use of a PC costs more than the PCs them-
selves, but also yields a more sustainable effect. Public
service staff were found to be highly motivated to support
e- government. This important asset must be exploited
and increased in the interest of implementing
e-government. Focal issues include intensive staff
training as well as increasing the attractiveness of jobs
in public administrations for IT experts.
The use of e-government is strongly dependent on
customer acceptance of the services offered. Full
utilization of the savings potential of e-government is
contingent upon the online services provided being
accepted and used by potential users.
Expectations among citizens, companies and public
agencies as the specific target groups need to be
identified on an ongoing basis.
The service portfolio and the service rendering process
must be adapted to these expectations.
www.icta.go.ke
Legal guidelines must be considered in addition to the
organizational frame of reference.
The legally binding nature of electronic

communications is a crucial success factor for the
implementation of e- government. What is hence
needed is a digital solution for a signature with legally
binding effect, i.e. the electronic signature. The legal
adjustments necessary to enable the use of electronic
signatures in the various agencies need to be done.
E-government offers a host of options and

rationalization potentials in the IT sector. Ideally, data
from the most varied contexts is gathered once only
by a central function and is subsequently available to
any de-centralized purposes and uses.
However, when electronic data is exchanged within and
between public agencies, data protection requirements
must be considered and implemented by way of suit-
able technical and organizational measures. Personal
data, in particular, may not be gathered, processed or
disclosed for any purpose other than the use explicitly
contemplated by law.
People with disability (impaired vision and physical

handicaps), depend on technical aids as a precondition
for using the Internet. In order to op- timely enable
these devices for e-government applications, a host of
rules and requirements must be considered during
programming, designing and editing. Agencies are
required to ensure as much as possible that this group
is well catered for in pursuant to the constitution on
freedom to information and Equal Opportunities with
the aim of overcoming and preventing disadvantages
for disabled people in accessing the online services.
www.icta.go.ke
E-government services can be generally broken
down according to interaction levels,
i.e. information, communication and transaction.
Information primarily covers the provision of

information for the people, for businesses and other
elements of society. Users on this level merely act as
recipients of information..
Many of these information systems are supplemented
by communication solutions with dialogue and
participation offerings which enable the exchange of
news, messages and information. This offer ranges
from simpler solutions, such as e-mail or web-based
discussion forums, right through to more complex
applications, such as video conference systems for
tele-cooperation.
Transaction applications represent the highest
interaction level. This sector covers the real rendering
of services by organization. These applications include,
for example, the electronic receipt and processing of
applications or orders as well as the provision of forms
which can be filled online , Electronic payment etc.
The electronic signature is an important element that
ensures the authenticity and confidentiality of the data
exchanged between the different parties.
Besides the classification in terms of interaction

levels, the different partners involved in e-
government can also be distinguished.
This situation refers to the electronic interaction

between citizens and administrations. This area
also covers non- profit and non-governmental
organizations.
This term covers electronic relations between

administrations and business.
www.icta.go.ke
As already mentioned, public administration services
not only cover the field of pure services, but also rights
and obligations. A functional classification of
administrations is necessary as a precondition for
standardizing the different types of administrative
activity – and hence the possible transactions.
Generally valid types of transactional services can be
identified on this basis.
The public administration can be divided into service

and intervention functions based on responsibilities
and legal forms. Different services types can be
identified and classified as service-type and
intervention-type services on the basis of the different
categories of functional administrative branches.
Services are demanded, i.e. initiated, by citizens or

businesses from the administration. Services include:
Sub-steps, actions and roles of transaction services
The individual transaction types can be broken down

further into individual sub-steps. Sub-steps consist of
one or more actions in which different actors are
involved. Examples of sub-steps, actions and roles
related to the service area are discussed in the
following. This methodological approach can then be
used as a basis for developing similar models for any
other transaction type.
As a precondition for applying for a service, citizens

must first be given the opportunity to obtain detailed
information. The information step is followed by the
submission of the application. The application is passed
on to the public agency and from there to the officer
in charge. Other organizational units or public agencies
may have to be asked for comments or information.
As already mentioned, processes may have to be
optimized or reformed in this field.
www.icta.go.ke
The examination of the case is followed by a decision.
This decision, again, may have to be sent to other
departments or officers for information.
Finally the decision is communicated to the applicant.

If the decision corresponds to the applicant's request,
the case is closed and funds are disbursed, if
applicable. In this case, permanent control of the
application of funds must be possible. The procedure
ends with archiving as the last sub-step.
If the applicant does not agree to the decision,
remedies in law are available in the form of a protest
or legal proceedings, for example.
The individual transaction types can be broken down

further into individual sub-steps. Sub-steps consist
of one or more actions in which different actors are
involved. Examples of sub-steps, actions and roles
related to the service area are discussed in the
following. This methodological approach can then
be used as a basis for developing similar models for
any other transaction type.
As a precondition for applying for a service, citizens
must first be given the opportunity to obtain detailed
information. The information step is followed by the
submission of the application. The application is
passed on to the public agency and from there to the
officer in charge. This means that for the services the
sub-steps need to be defined and show the
interactions and contain further explanations.
The analysis of service types explained above
and the related identification of sub- steps, ac-
tions and rules can be used as a basis for iden-
tifying functional modules which – given the
required configuration possibilities – can be
used ´to implement different procedures using
information technology. The potential applica-
tions of these modules are dependent upon the
quality of the process analysis and the chosen
software architecture 33.
www.icta.go.ke
The following types of basic modules can be defined in
conjunction with the above- described procedure.
The analysis of the different roles leads to the need

to develop certain basic modules which enable
functions for access to the e-government
application. This includes a uniform user interface
which is easily remembered, as user and role
management functions as well as functions for
authenticating users in the system.
The actions identified are implemented in the form

of application modules, with priorities being
defined, for example, on the basis of their potential
frequency of use in the implementation of the
business logic. De-centralized and central modules
can be distinguished here.
The definition of basic modules leads to the

development of software or network- based
components which standardize communication
between the basic modules.
www.icta.go.ke
Annex A.2 Information viewpoint:
Schemas ensure uniform data grammar, semantics and

layout which ensures interoperability and data exchanged
between the e-government applications
The MCDAs are to ensure that common schemas and

identical definitions of elementary data types are used
throughout the system cycle. The use of XML schemas is
encouraged.
ANNEX A.3 Computational viewpoint
The computational viewpoint is introduced in order to

offer technical assistance when drafting e-
government applications, with special emphasis being
placed on reusability and interoperability. One central
aspect in this context is the integration of special and
technical applications into existing and future
e-government architectures and infrastructures.
Design decisions for the establishment of a software

architecture for e-government applications must
consider certain requirements and frames.
The MCDAs are discouraged from implementing

applications independently especially in cases where
multiple public agencies are involved in the rendering
of a service.
The rendering of online services without media

inconsistency is a central goal of ICTA and therefore
Insular solutions make this almost impossible or lead
to high costs when it comes to linking the various
systems together. MCDAs are encouraged to partner
up with all the relevant departments/Ministries to
ensure that the one solution can cater for all so as to
reduce on duplications.
www.icta.go.ke
Besides avoiding insular solutions and parallel
development work, the reorganization of process
chains is also recommended so as to simplify
complex administrative procedures.
Simplifying processes in special procedures enables

substantial cost savings when it comes to
implementing special applications. Furthermore,
error-susceptibility as well as updating and
upgrading costs can be reduced significantly.
Another central aspect in design decisions is to

ensure adherence to data protection requirements.
Despite all the advantages resulting from the
central, non- redundant storage of data, measures
must be taken to ensure adherence to all applicable
laws when storing and processing personal data.
The software architecture must hence include

certain security systems in order to ward off
manipulation of data and attacks by hackers.
There needs to be an agency-spanning co-operation

by linking together existing special applications and
using cost-intensive software components, such as
a payment platform or modules for supporting elec-
tronic signatures.
Reusability of software components and interoperability

of the individual applications and components are
indispensable preconditions for taking up these
challenges. The use of standardized and reusable
processes within the framework of a uniform and
standardized software architecture can help reduce
costs in the long term.
www.icta.go.ke
This standardized approach leads to uniform
interfaces when it comes to drafting and implementing
software projects.
The basic modules must be integrated into software
architecture as a precondition for their use in
conjunction with the implementation of special
applications.
Any system to be developed must fulfill a number of

Basic general requirements as detailed below:
requirements
for a software a. Security
architecture Confidentiality, authenticity and reproducibility as
well as compliance with the government Data
Protection Act and the relevant security standards
must be ensured in the use of e-government
applications.
b. Reusability
Reusability of an e-government application or of
one of its components is one of the central
requirements which is to be achieved by adhering
to the architecture. Redundant development of
applications for similar or identical services is
thereby avoided, so that cost savings can be
achieved in the long term. Furthermore, the use
of tried-and-tested modules enhances the quality
of the entire system.
c. Flexibility
Adjustment to new frames of reference as well
as upgrades are easily possible and/or at a
reasonable cost.
E-government applications must be designed in
such a manner that modifications of or
amendments to an application – resulting, for
example, from changes in legislation, process
optimization or use by other public agencies – can
be carried out in an effective manner and at a
reasonable cost.
www.icta.go.ke
d. Openness
In order to enable simple integration of existing or
new systems, the system in use must include
well-defined and well-documented interfaces. The
openness of an e- government application is one
of the crucial factors for its successful use.
e. Scalability
Distribution of an e-government application or its
individual components must be possible without
any problems. This is the only way to ensure the
ongoing use of an application in an efficient and
performant manner as use increases. Especially in
the case of an application which is centrally
operated, the number of public agencies using it is
not definite, so that its future, cost- effective
scalability must be ensured when the number of
public agencies and users increases.
f. Performance
A short response time of an application is vitally
important in order to ensure its widespread
acceptance among citizens and businesses.
Complex transactions often require processing
large amounts of data. The successful use of an
application is contingent upon the user-friendly and
performance provision of data.
g. Availability
Access to e-government applications must be
permanently ensured. A permanently available
application signals reliability and trustworthiness,
so that citizens and businesses become more and
more willing to use the application and to supply
the – typically confidential – data necessary for the
transaction represented by the application.
www.icta.go.ke
Systems and applications ICTA 2016 First Edition 2016
h. Error tolerance
The system must be capable of handling unforeseen
and invalid system states. Errors or unforeseeable
events may not lead to a crash or uncontrolled
system behavior which the user is unable to
understand. Faultless, transparent operation of an
application is a vital prerequisite for the user's
trust in complex transactions.
i. Updating capability
Operation and updating of e-government systems
should be as simple and easy as possible. External
experts who were not involved in the development
of the system must be capable of ensuring
efficient system maintenance and updating even
without longer familiarization time.
The software architecture outlined here involves
several fundamental design decisions. These are the
mandatory use of object-orientated software
development paradigms and a component-based
software development approach on this basis.
Component-based software development enables the
compiling of software from existing components and
their reuse. This system is expected to yield several
positive effects, such as:
a. faster development and provision of the application
b. lower costs
c. higher quality
d. less complex structure
e. flexible application systems and modern system
architectures
However, the use of component-based software

development not only has positive consequences. We
recommend the use of software components due to
project cycle times and the high share of similar and
comparable applications.
www.icta.go.ke
In order to develop robust, reusable components,
clear-cut functional definitions of the components
are necessary in order to generate maximum
benefits by reducing parallel development efforts.
Separating presentation and business logic offers a

technical solution for the optimum support of multiple
presentation channels, such as different browser types
or mobile devices, such as personal digital assistants
(PDAs). Besides this aspect, the separation of presentation
and business logic significantly enhances the quality of
code structure, thereby substantially improving updating
and trouble-shooting capabilities, flexibility, reusability
and reproducibility whilst at the same time lowering costs
in the medium term. Furthermore, such a separation
enables the potential distribution of an application to
several servers, with one server being responsible for
the presentation tier and another one for the business
logic. This has a positive impact on operation with regard
to security, upgrading capability and scalability aspects.
The separation of business and data logic leads to
applications which are independent of the database
type. At the same time, functionality is not directly
dependent on the database via abstraction and
performance, for example, by caching.
The implementation of the above-stated aspects

leads to a multi-layer architecture with four tiers.
The implementation of a special application in tiers
with the inclusion of components calls for a clear-cut
assignment of components to a specific tier. This
facilitates the classification of components and
implies formal definitions of their functionalities.
The individual tiers of the multi-tier architecture

are the client tier, the presentation tier, the middle
tier and the persistence tier / back-end.
a. The client tier is where users and application
software interact.
www.icta.go.ke
The data processed by the presentation tier as well as
the user interface are visualized.
b. The presentation tier is responsible for presenting
the application data (for example, as a website).
c. The middle tier, also called the application tier,
accommodates the most important components for
implementing the application logic irrespective of
their presentation. This is where the program
sequence is controlled. The data from the
persistence tier is processed accordingly and
passed on to the presentation tier where user
entries are validated or authorization is granted, for
example. An optional part of this tier integrates
central components, legacy or ERP systems, when
necessary. External services can be given access
via application interfaces to the application without
having to use the presentation tier.
The persistence tier is responsible for the storage of
data objects. It abstracts from the database. The
back-end as a collective term represents
functionalities of the operating system, specific
databases as well as existing, non-SAGA-con-
forming special applications, legacy or ERP systems.
www.icta.go.ke
Figure A: four-tier architecture for e-government applications
The multi-tier architecture is preferably implemented using the Java programming

language The decision in favor of Java is based on its platform-independence, optimum
support of object- orientated software techniques, stability of the execution environment
and the large number of free and commercially available APIs.
30 The ICT Authority is a State Corporation under the State Corporations Act 446
www.icta.go.ke
Annex A.4 Engineering viewpoint: reference infrastructure
The selection of the appropriate infrastructure is a
central success factor when it comes to planning,
designing and operating e-government applications. A
stable and secure IT infrastructure is the basic
precondition for the reliable operation of e-government
applications with high reliability. Today's data
protection, data security, efficiency and availability
requirements for e-government set high standards
for operators of applications and infrastructures.
The reference infrastructure for e-government
applications is modelled on the basis of the engineering
viewpoint according to RM-ODP and describes the
encapsulation of system units and their connections.
Not every public agency requires its own, complete e-
government infrastructure. Smaller institutions may
well use the Government Data Centre or sister
agencies.
Design of an The introduction of a reference infrastructure in SAGA
e-government serves the aim of defining the infrastructural
infrastructure preconditions necessary for the operation of e-
government applications and the required system
architecture. The following goals are to be achieved
by defining parameters or a reference infrastructure
in the sense of an operating environment.
a. Physical protection of systems
b. Maximum availability of systems
c. Increasing the security of systems and system
components through classification on the basis of
their protection demand
d. Classification of systems and system components
according to separate security zones
e. Scalability of systems and infrastructures
f. Simple service, efficient maintenance and updating
of complex e-government applications and system
components by operating personnel
The figure below shows a general overall view of a
distributed e-government application with the user,
network and infrastructure areas.
www.icta.go.ke
Figure 5:
32 www.icta.go.ke
Physical The protection of systems against external influences,
infrastructure the elements and unauthorized access requires the
provision of suitable space. Computer centres
designed to host e- government applications should
hence at least feature the following properties.
a. Fire resistant, structurally enclosed security space
protected against radio interference.
b. Access control, including personal authentication
c. Fire-extinguishing system with non-corrosive and
non- toxic extinguishing agents
d. Redundant power supply, including uninterruptible
power supply
e. Redundant air conditioning system
f. Data backup media in a fire-resistant vault outside
the computer centre
Process Mandatory: Role models and flow

modeling
Role models and flow charts can be used to define
simple processes. All the roles and systems related
to a process must be identified, and the process
steps must be described in the form of flow charts.
Unified Modeling Language (UML) should be used for
object-orientated model- ling for the preparation and
documentation of large projects. Use cases are a
particularly tried-and- tested way of creating and
coordinating transparent specifications.
Functional data models for the development of

coarse technical concepts are to be presented in
the form of Entity Relationship Diagrams
The data specification is to be implemented as an

XML schema
www.icta.go.ke
XML (Extensible Markup Language) is to serve as the
universal and primary standard for the exchange of
data between all the information systems relevant
for administrative purposes.
New systems to be installed should be capable of

exchanging data using XML. Existing systems do not
necessarily have to be XML-enabled.
If necessary, it is also possible to use middleware
which interprets incoming XML information and
transforms or converts such information to the data
format required by legacy and/or external systems.
XML schemas according to World Wide Web

Consortium (W3C) 55 are to be generated using
the XML Schema Definition (XSD) for the
structured description of data.
If applications use different

XML schemas, conversion from one format to another
can become necessary for data interchanging
purposes. This format conversion is carried out via the
XSLT56 language defined by W3C as part of XSL
(Extensible Style sheet Language).
Protection aims define the security interests of

communication partners in a general form:
a. – protection against disclosure to
unauthorized parties:
No data is made available or disclosed to
unauthorized individuals, entities or processes.
b. – protection against manipulation:
Unauthorized modification or destruction of data is
not possible.
www.icta.go.ke
identity/origin:
Measures are taken to ensure that an entity or
resource (such as an individual, process, system,
document, and information) actually is what he, she
or it claims to be.
– protection against failure of IT systems:
The properties of an entity and/or resource can be
accessed and/or used when this is attempted by an
authorized entity.
Information encryption (cryptography) is an important
tool for securing confidentiality, integrity and
authenticity.
A high degree of availability is achieved through

multiplicity, distribution and error tolerance.
Annex B.1: Acquisition

Standards for Developing and Maintaining Computer
Applications
• Source control: Changes to existing systems and
application software requires:
- Procedures for segregating production and test code
-Procedures for checking source code in and out
-Procedures for testing the changes in stages of
increasing impact
-Standards for identifying the changes that were made
(including the date of the change and the name of the
programmer)
-Procedures for notifying others of the changes
-Procedures for user review of functionality and
presentation
-Criteria for installing the modified source code in
production mode.
● User participation: Involve users at appropriate stages
of the change process.
www.icta.go.ke
For enhancements and program fixes, document
user participation (in the form or a log or other
format, including e-mail) so it is clear that
changes were not made at the discretion of the
technical staff alone. If changes do not affect
the functionality of an application (e.g., a
calculation) and are done for security,
reliability, or performance reasons, user
participation is not necessary. Follow
procedures for the:
• Receipt of requests for enhancements or
identification of system problems
• Identification, discussion, and resolution of
issues associated with the proposed changes
• Priorities for proposed changes, and discussion
and resolution of differences regarding
priorities
• If appropriate, cost and time estimates for
proposed changes
• User review and acceptance of testing
• User review and acceptance of completion of
the changes and readiness for production
System Development tracks and phases: The standard
describes the phases of a systems development
project. The exact methods employed for systems
development will vary depending on the specific
project. Although every systems project is unique,
there are three key characteristics which will
influence the overall approach chosen for systems
development:
• The overall size and complexity of the application
• The technology to be used for developing the
application
• Whether the system will be a purchased package,
or custom developed
Three separate development approaches or "tracks"
have been identified for consideration:
• Prototyping: appropriate for custom development
of smaller systems or systems that use newer
technology such as Web-based development tools.
www.icta.go.ke
• Traditional life cycle approach: more suited to custom
development of larger systems, such as mainframe
applications
• V e n do r pac kag e : c o v e r s t h e pu r c h ase an d
implementation of vendor packages.
Some phases of project development apply to a
combination of two or more approaches, whereas others
are unique to one approach. The Project Leader is
responsible for making recommendations regarding the
best approach for a project, and keeping appropriate
records. Prototyp Traditio Vend
Development
ing nal or
2.1 Project proposal X X X
Planning 2.2 Request for info X
Planning 2.3 System Definition X
Analysis X X Analysis
2 . 5
2.6 Request for proposal X Analysis
2.7 Feasibility *Optional *Optional Required Analysis (*see
below) 2.8 Vendor Contract Plan X Analysis
2.4 Prototyping X Prototyping
2.9 General Design X Design
2.10 Detail Design X Design
2.11 Programming/ testing X Development/
testing 2.12 System testing X X X Testing
2.13 Implementation X X X Implementation
2.14 Final Documentation X X X
Implementation
a.MCAs shall consult the ICT Authority when

embarking on major software and applications
acquisition
b. ICTA in collaboration with MCAs shall ensure that
there is no already existing software application
within Government that provides equivalent
functions and that can be replicated in the
organization before procuring any software to avoid
duplication.
c. ICTA in collaboration with MCAs shall ensure that
the architectural model for e-government
applications is complied to.
www.icta.go.ke
d. Acquisition of the software shall be done with
consultation and coordination of the Head of ICT Unit
who shall be responsible for liaising with ICTA in the
preparation and issuance of all technical
specifications for the software, as well as ensuring
that the guidelines stipulated herein are adhered to.
e. MCAs shall use requisition and acceptance forms
to ensure that requests for procurement of software
are validated by the respective Heads of Department.
f. MCAs shall also ensure that requirements are
clearly defined and documented when procuring
enterprise software.
g. Where possible, MCAs are required to use
enterprise version of software.
h. Users may not give software to any third parties
including clients, customers and contractors. Users
may use software on networks or on multiple
machines only in accordance with applicable licence
agreements.
i. Software will only be installed by ICT officers in MCAs.
Users are not authorized to install any software on
computers
j. MCAs are required to procure and use the latest
version of software. Where a previous version of
software is to be used, MCAs shall be required to
give justifications.
www.icta.go.ke
a. The software development process shall adopt a
project management approach as stipulated in
project management standard.
b. MCAs in collaboration with ICTA shall ensure that
an optimal system development methodology
such as software development lifecycle is adopted
in order to obtain a useful system.
c. The MCA in collaboration with ICTA shall

constitute a development team consisting
of various specializations as may be required
in specific software development task. These
shall include software developers with
expertise in target development platform,
business/systems analysts, business/systems
designers, database experts, network and
communication,security specialist among other
skills that may be required in different project.
d. In developing information systems, MCAs shall to
the greatest possible extent develop, create and
procure software based on the use of open
standards.
a. For sophisticated system development initiatives
that require skills and knowledge not available
within MCA, an external developer may be
contracted to deliver the business application. In
this case, the MCA in collaboration with ICTA
will adopt a project management approach as
per project management standard and constitute
a technical team consisting experts in the business
process, business/systems analyst and the
relevant ICT skills.
b. The process shall follow a system development
methodology
c. In developing information systems, MCAs shall
to the greatest possible extent develop, create
and procure software based on the use of open
standards.
d. The minimum requirements that must be
considered in the system development are:
www.icta.go.ke
• This cost includes initial costs
such as purchase, installation and training, plus
the ongoing cost of maintenance and support.
• This criterion addresses the ability

to administer and perform corrective, adaptive or
perfective maintenance on the system within
defined tolerance for cost and service, using
vendor and/or internal support. This criterion
includes minimal operational disruptions and
downtime, the ability to tune the software to
improve efficiency and effectiveness and the cost
and effort to upgrade to improved versions of the
software product.
• This criterion seeks to minimize
the additional support required to integrate with
existing systems Interoperability should include
flexibility in supporting changes over time and
among multiple state agencies and systems.
Interoperability standards affecting more than one
Agency will be mutually determined and
consistent with all higher-level standards.
• This criterion addresses the ability of

an existing software component to move from one
physical or logical position in the IT infrastructure
with minimum impact on cost and service.
• This criterion ensures that acceptable

solution enhances the ability of the system to
support future growth and increased throughput
necessary to meet e-Government goals.
• This criterion seeks
to maintain a system's operational readiness and
www.icta.go.ke
required level of service without disruption from
software failure. This is achieved through robust
and/or redundant (e.g., fault tolerant) software.
Operational readiness will include the ability of
users and operators to access the system, in a
timely fashion, to perform its intended functions.
• This criterion addresses the ability

to make repeated use of the system for
additional requirements with minimum
additional cost.
• This criterion seeks
to guarantee that the Operational requirements,
especially its mission critical requirements,
intended to be performed by IT systems, can be
achieved effectively and efficiently with the
specified solution. It includes the properties of
efficient system/hardware integration that affects
the ability of the overall system to perform
adequately to meet operational requirements.
• This criterion addresses the need to

protect system data and the operational
environment from loss or compromise. It includes
the ability of the software to prevent and contain
malicious as well as non-malicious security
breaches.
• The evaluation criteria at minimum shall take

into consideration the following stages
a) Mandatory technical aspects
b) The detailed technical specifications
c) Demonstration of the proposed solution
d) Due-diligence
• An audit of the development process shall be done
as per Appendix 8
www.icta.go.ke
Below are the minimum requirements that must be
considered in the acquisition of COTS:
a. This cost includes initial costs
such as purchase, installation and training, plus the
on-going cost of maintenance and support.
b. This criterion addresses the ability

to administer and perform corrective, adaptive or
perfective maintenance on the COTS product within
defined tolerance for cost and service, using vendor
and/or internal support. This criterion includes
minimal operational disruptions and downtime, the
ability to tune the software to improve efficiency and
effectiveness and the cost and effort to upgrade to
improved versions of the software product.
c. This criterion seeks to minimize

the additional support required to integrate the COTS
product as a functioning component in the State IT
portfolio. As an example, the exchange of information
between potentially heterogeneous systems can be
facilitated through open standards or non-
proprietary protocols (e.g., TCP/IP). Interoperability
should include flexibility in supporting changes over
time and among multiple state agencies and systems.
Interoperability standards affecting more than one
Agency will be mutually determined and consistent
with all higher-level (e.g., Statewide) standards.
d. This criterion addresses the ability of
an existing software component to move from one
physical or logical position in the IT infrastructure
with minimum impact on cost and service.
e. This criterion ensures that acceptable
COTS software products enhance the ability of the
system to support future growth and increased
throughput necessary to meet e-Government goals.
www.icta.go.ke
This objective is achieved through excess capacity

or the flexibility to easily modify and/or enhance
the system as needed (e.g., application
performance or transaction process speed, forward
and backward compatibility, modularity, etc.).
This criterion seeks to

maintain a system's operational readiness and
required level of service without disruption from
software failure. This is achieved through robust
and/or redundant (e.g., fault tolerant) software.
Operational readiness will include the ability of
users and operators to access the system, in a
timely fashion, to perform its intended functions.
This criterion addresses the ability

to make repeated use of the COTS software product
for additional requirements with minimum
additional cost.
This criterion seeks

to guarantee that the Operational requirements,
especially its mission critical requirements,
intended to be performed by IT systems, can be
achieved effectively and efficiently with the specified
COTS software. It includes the properties of
efficient software/hardware integration that affects
the ability of the overall system to perform
adequately to meet operational requirements.
This criterion addresses the need to

protect system data and the operational
environment from loss or compromise. It includes
the ability of the COTS software to prevent and
contain malicious as well as non-malicious security
breaches.
www.icta.go.ke
Other criteria are
explicitly used for specifying the acceptable set of
COTS software products. For example, vendor
viability, licensing restrictions, potential product
market share, customer recommendations, and
product volatility (e.g., frequency of upgrades
and potential obsolescence) may be important.
Acquisition of such software shall follow a project
management approach as per the project
management standards and shall follow a
development methodology
In developing information systems, MCAs shall to
standards.
For specialized applications,the functional
requirements are
a. MCAs treat open source software and proprietary

software equally. In all the procedures of software
development and procurement, the choice shall be
based on the financial and functional properties of
certain software regardless of the existing business
relations or model in use
b. In developing information systems, MCAs shall to
standards.
c. MCAs shall avoid the use of software which is
difficult to interface with other software or data
exchange between software of different information
systems in MCA. In cases where this is not possible
due to closed nature of the legacy software, all
subsequent upgrading and modifications in these
systems shall have to be based on the support of
open source software and open standards. This will
enable the connecting of information systems
across Government.
www.icta.go.ke
d. When it is economically or financially justified,

MCAs shall request from the supplier full ownership
and the right to use and distribute the source code
of procured software. The MCA shall put to public
use the software for which ownership was obtained
and software whose creating was financed from the
budget funds, together with the licenses obtained
with the procured software.
e. MCAs shall Promote software development based
on the open standards in the process of developing
the existing information systems in GoK agencies.
Through these actions, the Government shall
promote the development of domestic proprietary
software based on open standards.
• MCAs shall ensure licenses for commercial operating
system are provided upon acquisition, duly registered
and subsequently renewed as per the requirements of
the copyrights
MCAs should ensure that there is Service level
agreements signed with the vendors.
MCAs shall ensure the latest stable version is
purchased in each case;
The units shall organize training for users on any
new client operating system software.
MCAs shall ensure that ICT officers responsible for

development of software are adequately trained on all
application software acquired.
MCAs shall take into consideration the following when

acquiring application development software:
i. Type of application to be developed; Desktop
application, Web based application or server
application.
ii. Operating System platform the software to
be developed is to run on.
iii. Integration with the existing systems.
iv. Database to be used by the application.
v. Compatibility with existing and future hardware
and software platforms.
www.icta.go.ke
vi. Speed of development.
vii. Performance of compiled code.
viii. Assistance in enforcement of code
ix. Portability; can the application developed be
used in an operating systems other than the one in
which it was created without requiring major rework.
x. Fitness of the software for the application being
developed.
MCAs shall ensure that all systems have the
following documentation
a.Project initiation documentation detailing the
business case
b.Feasibility study detailing the proposed
solution
c. Detailed user and technical requirements
d. High level and detailed system design
documents
e. System testing and commissioning
documentation
f. Evidence of user and technical training
g. User and technical manuals
h. Certificate of completion
www.icta.go.ke
Annex B.2: Procedure for Selecting Whether to Develop or Acquire
This decision may be taken early in the project if some of the following questions can be
answered during Project Initiation. However, in some cases, the Ministry or Agency may have
to wait till the Functional Specifications are available before it can decide.
(Review the Analysis of Requirements and the Functional Design processes in the Project
Planning Phase).
In all cases, the response should be fed through the Evaluation Framework presented in a
separate segment which requires two types of criteria.
Figure B.2 : Selection Criteria for Developing or Acquiring Software
Here are the broad steps to go through along with the evaluation criteria to be used.
Figure B-2: Steps to Decide Whether to Develop or Acquire
www.icta.go.ke 48
Step 1: Decide on the Mandatory Conditions
Acquire the software if any of these questions apply and are positive:
- Is the software readily and cheaply available on the market?

- Is the ICT development unit incompetent in this technology?
- Is the ICT development unit overloaded?
- Is the delivery time critically short?
- Is software reliability critical?
Develop the software if any of these questions apply and are positive:
- Are the requirements very specific to the organization so they cannot be found in the
market?
- Is available commercial package prohibitively priced?
- Will software vendor not supply source code or supply it at prohibitive prices?
- Is support critical AND not available?
Step 2: Evaluate the Criteria for Acquiring or Developing
Assuming that a clear choice was not arrived at in Step 1, it follows that the decision has to
be made based on evaluating different criteria that describe the situation for developing or
acquiring software.
Here are example criteria:
49 www.icta.go.ke
Figure B-2: Criteria for Deciding Whether to Develop or
Notice that the first two criteria are pre-filled for developed software since it is assumed that
for the first criterion, the developed software is very close to all the requirements. Secondly,
the cost of the source for developed software is zero.
On completing the above evaluation as per the procedures of the Evaluation Framework, the
Ministry or the Agency will be able to decide whether to acquire or develop the software.
Step 3: Evaluate the Commercial
If the decision is to acquire software, then using the Requirements Definition Document as
well as the Functional Specifications both developed during the Planning Phase, the
Ministry or the Agency can evaluate the most suitable offer based on the various criteria
defined in these two documents.
The diagram on the following pages shows the steps taken in a typical software
applications project. It shows the decisions to be made when deciding on acquisition
www.icta.go.ke
Figure B-2: Activities in the Phases of a Software Application
51 www.icta.go.ke
ANNEX B.3 Maintenance
ICT Unit s shall keep an inventory of all software in the

MDA, and give annual reports on status of utilization,
support and adaptability with the following attributes
- Systems name
- Systems purpose
- Supporting technologies
- Number of users per system
- Number of ICT support staff
- Organisational coverage
- Scope of use
- Anticipated end-of-life
- Commercial name
Software media and administration

documentation, whether hardcopy or electronic, shall be
securely stored in a central repository and copies may
be created for backup and disaster recovery purposes as
permitted by the license terms and conditions.
The MCA shall gather the cost for each application with
the following attributes:
- the original capital value/ estimated
replacement cost of the application.
- Operational costs
- Depreciation costs
- Licensing costs
- Maintenance costs
- Development and enhancement costs
- Annual estimated cost of operation
The MCA shall assess future business value of the
applications and prepare a report in terms of :
- Functional percentage utilization
- % link to business objectives
www.icta.go.ke
- Business priorities support
- Legislative and political support (does it support political or
legislative requirements).
- Enhanced service delivery.(expected to enhance the current delivery
of services to customers).
- Future measurable benefits. (Expected to provide additional
realizable benefits in the future).
- Future risk reduction. (Contribute to the reduction of business
risks).
- Future organizational innovation, (change and growth enables
individuals or business units to quickly respond to opportunities,
changes in the operating environment and the changing needs of
stakeholders).
Future fiscal benefit.( expected to increase revenue or reduce
operating costs in the future).
The MCA shall prepare a report on the condition of the applications in
terms of:
- : (supports
organizational architecture principles, policies, positions and
standards.
- supports
GEA architecture principles, policies, positions and standards.
- level of integration with existing systems
- : type and level of authentication for access and if
there is an audit capability being used
- Some skills available. Documentation OK. If
applicable, some compliance with corporate coding
standards. Partially automated scheduled deployment
www.icta.go.ke
- level at which it can easily
accommodate heavier loads i.e. new users and/or
new sites.(e.g Requires total or highly significant
investment or Heavier loads i.e. new users and/or
new sites can be accommodated to a certain
degree or Can easily accommodate heavier loads
i.e. new users and/or new sites or Requires little
or no significant investment or threshold
limitations lead to performance degradation).
- level of Reliability (e.g. Very unreliable

-often down or causes data errors. Availability 95%,
Crashes regularly, Reliable and small outages for
maintenance. 99.9% or better.)
- :
Occasional performance issues.
How it is Users avoid it whenever they

can. Difficult to use. High number of calls for help
from users. Requires significant training. Easy to
use. Few calls for help from users. Requires
minimal training. Help easily accessible.
www.icta.go.ke
54
a. Other than vendor supplied patches,
commercial-off-the-shelf (COTS) software
shall not be modified except in exceptional
circumstances when needed for a critical
business requirement. This requirement
shall be documented and approved by the
Information Owner and Information
Custodian
1. If changes to COTS software are required,
the Information Owners and Information
Custodians shall determine:
● The effect the change will have on
the security controls in the software;
● If consent of the vendor is required;
● If the required functionality is included
in a new version of the software; and
● If Central Government and MDAs will
become responsible for maintenance
of the software as a result of the
change.
2. If changes are made to COTS software the
original software shall be kept unaltered
and the changes shall be:
● Logged and documented, including a
detailed technical description;
● Applied to a copy of the original
software; and
● Tested and reviewed to ensure that
the modified software continues to
operate as intended.
• MCAs shall determine which software have

expired licenses for the purposes of upgrade.
Where such systems have proprietary data, that
data shall be extracted using suitable
mechanisms
www.icta.go.ke
• MCAs should ensure that there is Service level
agreements signed with the vendors.
A software update management process

shall be maintained for COTS software to
ensure:
● The most up-to-date approved patches have

been applied; and
● The version of software is vendor supported.
a. Software maintenance shall be done in-house

by ICT Units who shall develop a maintenance
schedule on upgrading and debugging.
b. Sub-contracting for software maintenance shall
be through appropriate justification and approval
by the Accounting officer in. Due diligence shall
be undertaken in retaining such contractors.
c. The Head of ICT Unit shall prepare an annual
maintenance report and forward it to the
Accounting Officer.
d. Software media shall be tagged with the
standard government labeling conventions and
appropriately physically secured.
MCAs shall ensure that all software and
applications are audited annually to ensure
they comply to information security standard
a. MDAs shall ensure that ICT officers
mandated to maintain or support software
acquired are adequately trained.
a. b. Where a maintenance contract is in place, MCAs
shall ensure that measures are put in place to
enforce knowledge transfer to ICT officers by
contractors and vendors for continuous support and
maintenance of the system once the contract expires.
www.icta.go.ke
Annex B.4: Disposal
● Disposal of software shall only take place when it is

formally agreed that the software is no longer required
and its associated data files which may be archived won’t
require restoration at a future point in time.
● Any GoK information processing equipment that is to
be disposed of or re-used shall undergo a cleansing
process before release.
● The cleansing process shall consist of destruction of the
licensed software residing on the equipment, testing and
validation of the process to ensure no software is left on
the equipment.
● Media which are marked as containing highly sensitive
information shall be physically destroyed.
Annex C.1: Email and Instant Messaging Policy
Official Staff members shall use

communicat
ion
· Communicate with citizens, service pro-
viders and suppliers of goods and services
· Promote the government image and ser-
vices
· Distribute/share information to col-
leagues
● Disseminate public information
Access ● Personal email use shall be of a

reasonable level and restricted to non
work periods, such as breaks and
during lunch.
● All rules described in this policy apply
equally to personal email use for
instance, use of inappropriate content,
www.icta.go.ke
large attachments is always
inappropriate, no matter whether it is
being sent or received for business or
personal reasons.
● Personal email use must not affect the email
service available to other users. For
instance, sending exceptionally large files by
email could slow access for other employees.
● Users may access their own personal
email accounts at work via government
Internet connection. For instance, a staff
member may check their Yahoo or Google
Mail during their lunch break.
Privileges and - Only persons duly authorized to use

Responsibilities government email may do so. Authorization
will be provided by the department
responsible for ICT through the employee’s
supervisor.
- It is typically granted new employees joining
the service will be assigned their login
credentials upon perusal of this policy,
training and committing to understanding
the policy by signing the declaration/consent
form.
- The signed declaration form will be filed in
the officers personal file. Disciplinary
action may be taken against an officer
who willfully breaches the requirements
of this policy.
- Unauthorized persons and unauthorized
use of government email system are strictly
prohibited. Any employees who uses
government email without authorization —
or who provide access to unauthorized people
— may have disciplinary action taken against
them.
www.icta.go.ke
Acquisition
m.
- E-mail software shall meet specifications on
E-mail setup and

management
www.icta.go.ke
- Administrators of Email systems in MCAs shall
ensure high conformity to license requirements as
stipulated by the License Agreement statements,
copyright and intellectual property requirements
by software developers.
- The system administrators shall be held liable

in case of breach of any of license requirements
and obligations by the
- Cognizant that Email systems could be a source of

security vulnerabilities and information risk to the
overall ICT organization and infrastructure, MCAs
must ensure, to the extent possible, only most
recent versions of email software applications
are maintain. Where this is not possible, close
relationship with software developer must
maintain for software patching. MCAs therefore
shall ensure that the version of the email software
programmes is up to date at all times.
- Government email platforms shall be hosted

either internally within government premises or
externally through hosting and cloud services.
- In either case, the hosting environment shall meet
the specified environment and ambience
conditions requirements as shall be defined from
time to time.
- Email servers must be located in secure

environments that meet all security
requirements as stipulated in the government
security standards and guidelines
documents.
- MCAs shall conduct penetration testing regularly
on the E-mail server and document the results
- The email server shall be regularly backed up.
www.icta.go.ke
MCAs shall specify E-mail retention periods in consideration of the

legal requirements governing their line of business. They shall
consult their legal sections to determine the requirements in the
law.
MCAs shall ensure that
● Users must always use passwords for access to the emails

system and should never be disclosed.
● Users are required to change their initial/default passwords

at the first log on and thereafter change after every 3 months
or immediately in case an account or password is suspected
to have been compromised.
● Create strong passwords which are relatively hard to

break/guess. Strong passwords should have the following
characteristics:
● Contain both upper and lower case characters (e.g., a-z, A-Z)
● Have digits and punctuation characters as well as letters

e.g., 0-9,! @#$%^&*()_+|~-(/.,?<>';":[]{}`\=
● Are at least eight alphanumeric characters long
● Are not words in any language, slang, dialect, jargon, etc
● Are not based on personal information, names of family,

favorite sport, telephone numbers, etc.
- MCAs shall ensure that the government email system must

not be used to send or store inappropriate content or
materials. Inappropriate content and material includes;
pornography, racial or religious slurs, gender-specific
comments, information encouraging crime or terrorism,
or materials relating to cults, gambling and illegal drugs.
www.icta.go.ke
- The definition of inappropriate content or material also
covers any text, images or other media that could
reasonably offend someone on the basis of race, age, sex,
religious or political beliefs, national origin, disability,
sexual orientation, or any other characteristic protected
by law.
MCAs shall ensure that users do NOT:
● Write or send emails that might be defamatory, diminish

the image of the officer or the office, or cause
embarrassment or liability to the government.
● Create or distribute any inappropriate content or material

via email.
● Use email for any illegal or criminal activities.
● Send offensive or harassing emails to others.
● Send messages or material that could damage the image

and reputation of government.
● use of government communications systems to set up

personal businesses or send chain letters,
● forwarding of government confidential messages to

external locations,
● distributing, disseminating or storing images, text or

materials that might be considered indecent,
pornographic, obscene or illegal,
● distributing, disseminating or storing images, text or

materials that might be considered discriminatory,
offensive or abusive,
● content perceived as personal attack, sexist or racist, or

might be considered as harassment
● accessing copyrighted information in a way that violates

the copyright
● breaking into the government's or another organization’s

system or unauthorized use of a password or mailbox
www.icta.go.ke
● broadcasting unsolicited personal views on social,
political, religious or other non-business related
matters
● transmitting unsolicited commercial or advertising

material
● undertaking deliberate activities that waste staff effort

or networked resources
● introducing any form of computer virus or malware
into the corporate network
● Users shall not use government email to share any

copyrighted software, media or materials owned by third
parties, unless permitted by that third party.
● Employees therefore, must not use the government email

system to perform any tasks that may involve breach of
copyright law.
● Users shall keep in mind that copyright on letters, files and

other documents attached to emails may be owned by the
email sender, or by a third party. Forwarding such emails
on to other people may breach this copyright.
●Users are careful about making commitments or agreeing

to make purchases via email.
● An email message may be construed to form a legally-

binding contract between an organization and the recipient
— even where the user has not obtained proper
authorization within the company.
www.icta.go.ke
- The standard government email template shall include an
email disclaimer. Users must not remove or change this
disclaimer when sending email messages.
All email campaigns must be authorized by the marketing manager

and implemented using the government's email marketing tool.
Users must not send bulk emails using the standard business
email system.
- MCAs shall examine the systems and inspect any data

recorded in those systems.
- MCAs shall use monitoring software in order to check on

the use and content of emails. Such monitoring is limited
to legitimate purposes only and will be undertaken in
accordance with a procedure agreed upon with employees.
Where it is believed that an employee has failed to comply with

this policy, they shall face the public service disciplinary procedure
as stipulated in the Code of Regulation of the public officers.
All government employees, contractors, interns or staff on

temporary terms who have been granted the right to use the
company's email services are required to sign agreement form
confirming their understanding and acceptance of this policy.
www.icta.go.ke
Annex C.2: Video and Audio conferencing Policy
VoIP software shall provide for:-

● Traditional calling features including call by name, caller ID, last number
redial, hold, call waiting, call forwarding , transfer, divert, park, retrieve,
voice mail, return call and call conferencing
● Call Coverage Make it easy to ensure that important calls are answered
by administrative assistants or team members, via user- controlled
Delegation and Team Calling respectively.
● Telephone Directory.
● Maintain Call history.
● Local Number portability, that is, ability to maintain phone numbers when
one changes service providers.
Protocols that are supported include:-
● Real- Time Transport Protocol.

● Session Initiation Protocol.
● ITU-T H.323
● Media Gateway control protocol
● IPSec, TLS and S/MIME for encryption.
a. MCAs shall ensure that all VOIP communications and systems are
secured by ensuring:
● 323 protocol is secured by using TLS and S/MIME encryption for SIP.
● Adequate physical security is in place to restrict access to key VoIP
servers and components.
● Firewalls designed for VOIP protocols are employed to secure the VOIP
systems.
● V O I P T e r m i n a l s a r e se c u r e d t h r o u g h pa ssw o r d
authentication and user authorization. User accounts shall be
administered and anaged by the ICT units.
● WiFi Protected Access (WPA) where mobile units are to be integrated
with the VOIP system.
● Disabling of HTTP and Telnet services
www.icta.go.ke
● Where softphones are used, PCs shall be adequately secured to
protect from worms, viruses, and other malicious software.
b. Creating awareness to users on how to secure use VOIP systems
c. MCA' shall ensure where possible that end-to-end encryption of the
VoIP conversations is employed.
d. Where possible, MCA shall endeavor to separate voice and data traffic
logically on the network due to bandwidth, security and Quality of service
requirement of VOIP.
a. VoIP Services must ensure Quality of Service to maintain the sound quality
of conventional phones.
b. Where possible, MCAs shall endeavor to separate voice and data traffic
logically on the network due to bandwidth, security and Quality of service
requirement of VOIP.
a. ICT units shall document and maintain an inventory of authorized

VoIP instruments and shall ensure that the VoIP systems only
register and use authorized terminals.
b. To avoid use of VOIP facilities by unknown terminals or PCs, MCA shall
employ use of device authentication through the use of MAC address.
www.icta.go.ke
Annex C.3: Social Media Use Policy
Prior to authorizing and enabling Internet access to Social Media

web sites, MCA management shall conduct a formal risk assessment
of the proposed connections utilizing Risk Management processes.
The assessment shall, at a minimum, include the analysis of the
risks (including risk mitigation strategies) involved in providing Users
access to Social Media web sites including:
● Employee productivity;
● Network bandwidth requirements and impacts;
● Reputational risk to personnel, the MCA, and the
Government;
● Potential avenue for malware introduction into the
organization's IT environment.
● The potential use of “other than government” sections
of Social Media web sites.
● The MCA shall document this risk analysis and retain
it for a minimum of two years upon which it must be
revised..
● Each MCA is responsible for its employees,' and

contractors,' and volunteers' compliance with this policy
and is expected to familiarize each user with this standard.
● MCAs are responsible for the investigation of alleged or
suspected violations of this standards, and the referral of
violations to ICT administrators for suspension of service
to users.
● MCAs are liable for any Terms of Use or service
agreements they agree to when creating social m e d i a
accounts.
● Social media sites are supported with technical and
monitoring measures which prevent or ensure the timely
removal of abusive, hateful, or defamatory submissions,
including information that jeopardizes the privacy of others
he ICT Authority is a State Corporation under the State Corporations Act 446
www.icta.go.ke
The MCA IT Administrators shall:
1. Limit Internet access Social Media web sites according to the
MCA's acceptable use policy, while allowing authorized Users
to reach content necessary to fulfill the business requirements.
Limitations may include:
● Opening Internet access only to the government sub-
domains on the Social Media web sites.
● Allowing Internet access to Users who are specifically
authorized.
● Preventing unnecessary functionality within Social Media
web sites, such as instant messaging (IM) or file exchange.
● Minimizing and/or eliminating the addition of web links to
other web sites, such as “friends”, to minimize the risk of
exposing a government user to a link that leads to
inappropriate or unauthorized material.
2. Enable technical risk mitigation controls to the extent
possible.
These controls may include:
● Filtering and monitoring of all Social Media web site
content posted and/or viewed.
● Scanning any and all files exchanged with the Social
Media web sites.
● Users shall connect to, and exchange information with,
only those Social Media web sites that have been
authorized by MCA management in accordance with
the requirements within this and other mca and
Government policies.
● Users shall minimize their use of “other than
government” sections of the Social Media web sites.
● Users shall not post or release proprietary, confidential,
sensitive, personally identifiable information (PII), or
other government Intellectual Property on Social Media
web sites.
· Users who connect to Social Media web sites through
Government information assets, who speak officially on
behalf of the MCA or the Government, or who may be
perceived as speaking on behalf of an MCA or the
Government, are subject to all MCA and Government
requirements addressing prohibited or inappropriate
behavior in the workplace, including acceptable use
policies, user agreements, sexual harassment policies,
etc.
www.icta.go.ke
● Users shall not speak in Social Media web sites or other
on-line forums on behalf of an MCA, unless specifically
authorized by the MCA management or the MCA’s Public
Information Office. Users may not speak on behalf of the
Government unless specifically authorized by the top
management.
● Users who are authorized to speak on behalf of the MCA
or the Government shall identify themselves by: 1) Full
Name; 2) Title; 3) MCA; and 4) Contact Information, when
posting or exchanging information on Social Media
forums, and shall address issues only within the scope
of their specific authorization.
● Users who are not authorized to speak on behalf of the
MCA or the Government shall clarify that the information
is being presented on their own behalf and that it does
not represent the position of the MCA or the Government.
● Users shall not utilize tools or techniques to spoof,
masquerade, or assume any identity or credentials except
for legitimate law enforcement purposes, or for other
legitimate Government purposes as defined in MCA
policy.
● Users shall avoid mixing their professional information
with their personal information.
● Users shall not use their work password on Social
Media web sites.
● There shall be an MCA department to manage MCA

presence on social media networks/platform.
● MCAs shall disseminate rules of engagement on social
media as
www.icta.go.ke
Annex C.4: Collaboration tools
Collaboration systems acquired by an MCA shall:-

- Support Features such as email messaging, IP telephony,
instant messaging, personal voice service, conference
call services, data conference services, document and file
sharing, collaborative document and file sharing,
forums, data conferencing (sharing of a white board),
short message service, chat, internal bulletin, address
book, video and single sign-on.
- Integrate with existing directory systems for access to
contact information.
- Enable grouping of users.
- Enable a single sign on to all the services.
- Provide electronic group calendaring and scheduling.
- Project management systems to schedule, track and
charts step in a project as it is being completed.
- Workflow systems to manage the collaborative flow of
documents and tasks.
- Intranet portal integration.
- Support different client operating platforms.
- Support common standards for interoperability with
collaboration systems in other MCAs.
- Support email push to mobile devices.
The collaboration tools shall conform to the following as per the
standards:
a. Ease of use
b. Agility
c. Scalability
d. Adaptable contexts
e. Low, flexible pricing
f. Support
www.icta.go.ke
Annex D.1: Web Governance
A digital asset management committee shall be constituted

to:
i. To align the digital asset with public vision, mission and
objectives;
ii. To ensure that the digital asset is of high quality and meets
its performance targets;
iii. To take responsibility for decisions made about the website.
1. The committee shall report to the head of the MCA and

Membership of the committee shall include;-
i. Head of Communication (Chair)
ii. Head of ICT (Secretary)
iii. Head of each line function in the MCA
2. The committee shall be responsible for ;-
i. Drafting of vision, mission and objectives of the organizational

digital asset for approval by the Chief Steward.
ii. Recommending the approval of the branding strategy, general
template and editorial policy of the digital asset
iii. Setting the performance targets of the digital asset and
reviewing performance reports.
iv. Reviewing the budget for the digital asset and recommending
its approval by the Chief Steward.
v. Monitoring and evaluating the digital asset, the user
feedback that it generates and making
recommendations for continuous improvement to the Chief
Steward.
vi. Making recommendations to the Chief Steward to
develop a new digital asset and / or to retire an
obsolete digital asset.
www.icta.go.ke
Meetings This committee shall meet whenever a major decision
about the digital asset is required, but not less than
once per quarter (for performance review.)
A digital Asset Composition The composition shall include;-

technical
i. Head of ICT (Chair)
committee
ii. Editorial Chief (Secretary)
iii. ICT Security Representative
iv. Web Master
v. Web Administrator
vi. ICT Networking Representative
vii. ICT Database Representative
viii. Information Representative
Responsibility i. Ensuring that the digital asset complies with

technical standards and requirements;
ii. Ensuring that quality assurance tests are regularly
carried out and performance measurements made;
iii. Security, technical quality and technical
performance of the digital asset.
Meetings I. This committee shall meet whenever a technical decision

about the digital asset is required, but not less than
once per month (for performance review.)
71 www.icta.go.ke
Annex D.2: Domain Management
a. Government Domain names can only be

registered using the .gov.ke / .go.ke .
Domain Providers reserve the right to waive
this rule if the stated purpose is multi -
jurisdictional in nature.
a. Domain names must bear a direct semantic

connection to the stated purpose. Furthermore,
such names should represent a readily
recognized concept associated with the stated
purpose.
Domain names must not:
i. be a personal name;
ii. exceed 40 characters in length,

including the first, second and top
levels of the domain name
iii. consist entirely of numerals;
iv. have the same name as an already

registered entity;
v. express a political statement or bear any

semantic connection to a registered
political party;
vi. contain obscene or offensive language or

otherwise prejudice the reputation or
credibility of the gov.ke domain;
vii. Infringe the intellectual property

rights of other parties. It is the
responsibility of the Registrant to
ensure compliance with this
requirement.
www.icta.go.ke
Annex D 2: Domain Management
viii. Domain names that comprise common words

should conform to the correct English/ Kiswahili spelling,
grammar and syntax.
ix. However use of aliases is not forbidden.
The domain must

i. be at least 2 characters long;
ii. short and simple
iii. easy to say
iv. easy to memorize
v. easy to spell and type
vi. stable i.e. no need to change if the structure
of the MDA's changes
vii. Contain only letters (a-z), numbers (0-9) and
hyphens (-), or a combination of these but
cannot start or end with a hyphen. Only one
hyphen is allowed, start and end with a
number or a letter, not a hyphen.
www.icta.go.ke
Annex D.3: Web Design, Inter- operability, Accessibility, Usability
1. All government websites shall be developed such that all

the web pages are viewable in standard compatible web
browsers, various operating systems such as Windows,
Macintosh and Linux and devices such as PC, PDA, tablets,
digital TV's and mobile phone based on the latest web
standards.
2. Server side scripting languages should be preferred over
client side since client side scripting may face issues of
browser compatibility, scripts being turned off by browsers,
security, among others.
3. MCA websites shall endeavor to use Cascading Style Sheets
(CSS) as much as possible to control layouts/styles.
a. During web development, MCAs websites shall validate to

following (or later) technologies for published grammars:
a. HTML 4.01
b. XHTML 1.0
c. XML 1.0
b. Ensuring that Web pages and Web feeds are encoded
in UTF-8 (UCS Transformation Format 8)
character code
c. All government websites should contain the following

mandatory elements;
a. Website Banner which shall contain among other;-
Coat of Arms or MCA LOGO where applicable, MCA
name, and colors of national flag where applicable.
b. About the MCA, and links to that shall contain among
other(where applicable):-
I. Organizational set-up
ii. Role and Functions (Mission, Vision,
Mandate)
www.icta.go.ke
iii. Major projects and Schemes
iv. Public Services
v. Publications e.g. Annual reports, strategy
documents, portfolio budget statements
vi. Customer Service Charter
vii. Government Tenders
viii. Press Releases / Announcements
ix. Associated Organizations (Related Links) c.
Contact Addresses / Telephone Number / Email of the
Senior Officers and Important Functionaries of the
Ministry/Department
d. A feedback/comment page and FAQS
e. Search Engine
f. Site Map
g. The design of the website or Web application is regularly
evaluated and improved through usability testing, such as
observing users completing tasks, throughout its life cycle.
h. Websites should be validated and tested with both automatic
tools and human review.
i. Ensure that users using assistive technology can complete
and submit online forms.
j. To aid those using assistive technologies, provide a means
for users to skip repetitive navigation links.
k. Provide a text equivalent for every non-text element that
conveys information.
l. Applets, plug-ins and other software can create problems
for people using assistive technologies, and should be
thoroughly tested for accessibility.
m. Provide text-only pages with equivalent information and
functionality if compliance with accessibility provisions
cannot be accomplished in any other way.
n. To ensure accessibility, provide equivalent
alternatives for multimedia elements that are
synchronized.
o. Design Web pages that do not have flashing lights/banners
and should not cause screen to flicker.
www.icta.go.ke
AnnexD.4: Web Branding
i.Placement and precise measurement of the main elements of

the page such as the banner, coat of arms, and primary menu
must be precise and conform to the official graphic design
template;
ii.The mandatory content of the landing page of a public website
is defined within the official graphic design template. This
content must be prominent and should be refreshed on a
regular basis.
iii. The main landing page of a Ministry, MCA or Department
that incorporates a number of state departments may adopt
an integrated format with an index to link to the landing page
of each state department.
iv. The landing page should have an index that links the page
to specialized pages which have been organized to provide for
the specific needs of citizens (G4C), Businesses (G4B) and
Government cross-MCA interaction where necessary (G2G).
Microsites and Intranets should follow the same branding
guidelines.
A public website must be formal, clear and readable. Sans serif

fonts with clean lines are preferred. It is preferable that only one
font is used throughout but not more than three fonts should ever
be used. Some suggested fonts for use on public websites;- Calibri,
Arial, Franklin Gothic Book, Geneva, Trebuchet MS, Lucida Sans
Unicode, Palatino Linotype, Times New Roman and any other good
web font.)
i. Public websites should only link to approved public digital

assets and approved social media. Links to commercial
sites,
commercial events and questionable external digital assets
are prohibited. Generally a link should be associated with a
specific keyword or an approved graphic element (such as an
official logo or an iconic photograph.) The mouse pointer
should change in a standard fashion to indicate proximity to a
link.
www.icta.go.ke
ii. Active and read links should be marked through a
standard colour-coding convention.
i. The correct branded logo or handle for the specific social

medium must be used at all times.
ii. A link to a social platform should be for the purpose of
accessing the associated page belonging to the public organ
and not for commercial promotion of the social medium.
iii. The public website of a public organ should only link to its
associated social platform if it regularly ensures that
content, breaking news and feedback are regularly updated
on the social platform.
iv. Every public organ that maintains a social platform must
appoint a moderator with the responsibility to monitor and
moderate social media conversations and perform quality
control.
- Photographs are useful for achieving an eye-catching and

attractive website. However, poor quality or busy photography
can mar a website and slow down its loading speed.
Therefore,
- Use sharply-focused photographs of reasonable pixel
strength;
- Use tools to optimize their file size to its lowest possible
value; - Caption them with a description of their date,
location, event, persons present and photographer;
- Consider the page proportions when choosing and placing
photographs – they should enhance the text – not dominate
it;
- Do not stretch them in a direction that distorts the proportions
of the image; and,
-
www.icta.go.ke
Since each photograph will download individually,
keep the number of photographs on a web page to a minimum.
- To retain the interest of the user, a web page should take between
3 and 18 seconds to load. Ensure that multimedia page elements
do not slow down the loading of a page beyond this point.
- Avoid automatic streaming of Voice, video and Podcast that can
unwittingly use up a user's credit when they are using a mobile
phone to browse your website.
- MCAs shall use search engine optimization (SEO) techniques to

ensure that your website is ranked highly by search engines
and appears first on search lists for relevant web searches.
i. MCAs shall host website in a secure location that conforms

to Government of Kenya standards to protect the Government
from the embarrassment of a defaced public website.
ii. If hosting a web-based application which accesses public
data you must ensure that the database is isolated from the
website and fully secured.
ii. MCAs must make every effort to ensure that your website
does not harbor any malicious code and that it is not being
used to harm your users.
i. Any information about users that is collected through

MCA website must be secured and protected against
unauthorized access.
ii. The text and multimedia published on your site must have
the necessary permissions for publication and should not
violate the privacy of the subjects.
iii. MCA shall always inform a user when and why you are using
a cookie to gather information about her.
iv. User information gathered by a cookie shall only be used to
improve the users experience on the website and should
be deleted as soon as it is no longer necessary.
www.icta.go.ke
i. The copyright of all content displayed on a website should
be visually acknowledged.
ii. All content that is not the copyright of the Government
of Kenya should only be displayed after the necessary
permissions or licenses are obtained from the copyright
holder.
iii. The source of all content items should be acknowledged
through a properly formatted citation.
iv. The conditions for use of Government of Kenya
copyright materials displayed on your website should
be stated at a suitable location on your website.
i. Always display a legal statement stating the boundaries

of Government responsibility for content on the
websites.
ii. Inform the public that information on the site is placed
in good faith and is general in nature and that before
they commit to the information they must counter check
to avoid any harm or losses.
iii. Users must be warned of levels of accuracy of material
facts. There should be a statement indemnifying the
Government from the content on linked websites.
iv. Keep a record of information on the site by backing up
the site on regular basis
I. While ICTA does not currently wish to require all Government

websites to conform to a single color code ICTA has developed
a sector color chart to guide the appropriate choice of colors for
public websites. Kindly liaise with the ICT Authority for guidance
if need be.
www.icta.go.ke
Annex D.5: Web Content
● Every image, video file, audio file, plug-in, etc. shall have
an alt tag
● Complex graphics shall be accompanied by detailed text

descriptions
● The alt descriptions shall describe the purpose of the

objects
● If an image is also used as a link, make sure the alt tag

describes the graphic and the link destination
● Decorative graphics with no other function shall have empty

alt descriptions (alt= "")
● MCAs shall add captions to videos
● MCAs shall add audio descriptions
● MCAs shall create text transcript
● MCAs shall create a link to the video rather than embedding

it into web pages
● MCAs shall add a link to the media player download
● MCAs shall add an additional link to the text transcript
● The page shall provide alternative links to the Image Map
● The <area> tags must contain an attribute
● Data tables shall have the column and row headers

appropriately identified (using the <th> tag)
● Tables used strictly for layout purposes do NOT have header

rows or columns
● Table cells are associated with the appropriate headers

(e.g. with the id, headers, scope and/or axis HTML
attributes)
● MCAs shall make sure the page does not contain repeatedly
flashing images
www.icta.go.ke
● MCAs shall check to make sure the page does not contain
a strobe effect
● A link shall be provided to a disability-accessible page

where the plug-in can be downloaded
● All Java applets, scripts and plug-ins (including Acrobat

PDF files and PowerPoint files, etc.) and the content within
them are accessible to assistive technologies, or else an
alternative means of accessing equivalent content shall
be provided
● When form controls are text input fields use the LABEL
element
● When text is not available MCA shall use the title attribute
● MCAs shall include any special instructions within field

labels
● Make sure that form fields are in a logical tab order
● Include a 'Skip Navigation' button to help those using text

readers
www.icta.go.ke
Annex D.6: Hosting
1. Host MCA website in a secure location that conforms to

Government of Kenya standards to protect the Government
from the embarrassment of a defaced public website.
2. If MCA are hosting a web-based application which accesses
public data you must ensure that the database is isolated
from the website and fully secured.
3. MCA must make every effort to ensure that your website
does not harbor any malicious code and that it is not being
used to harm your users.
4. The web master shall ensure that they are using the
latest/updated CMS.
5. Shall ensure that the CMS are regularly patched.
6. Website should be regularly scanned for vulnerabilities and
action taken in any.
7. The web master/web management committee should track
how many users have the key/root password and adhere
to other security requirement for applications.
8. Should always liaise with the host to ensure it's secure.
9. Web master shall always ensure root/critical files are
secured from unauthorized disclosure.
10. MCA shall always adhere with standards on data security,
and information management and other security
requirements while hosting your website and other online
systems.
www.icta.go.ke
Annex D.7: Monitoring and Evaluation
1. MCA shall ensure the homepage has clear inviting

introduction, showing key services at a glance and clearly
identifying organization owner.
2. MCA shall ensure the website branding and design identify's
organization, reflect audience needs and the logos and colors
represent the organization.
3. The navigation should allow user to find information they
want easily and has a common experience.
4. The content should be easy to find using popular search
engines
5. The site shall be organized around the way users think about
the information as opposed to having a strictly organizational
structure.
6. The information shall be comprehensive, well-written, and
meet the user's expectations and needs.
7. The website design shall strive to ensure that its accessible
to people with disabilities and those using assistive
technologies such as screen readers
www.icta.go.ke
APPENDICES
APPENDIX 1: COMPLIANCE CHECKLISTS
1 The MCA has mapped systems to business

processes and automated the relevant
functionalities?
2 The MCA has a systems asset register with the
following attributes?
-Systems name
- Systems purpose
- Supporting technologies
- Number of users per system
- Number of ICT support staff
- Organizational coverage
- Scope of use
- Anticipated end-of-life
- Commercial name
3 The MCA has gathered the cost for each

application with the following attributes?
- The original capital value/ estimated
replacement cost of the application.
- Operational costs
- Depreciation costs
- Licensing costs
- Maintenance costs
- Development and enhancement costs
- Annual estimated cost of operation
4 The systems/ applications asset register maps

business process to the applications. The register
identifies gaps in business automation and
proposes applications to fill the void.
www.icta.go.ke
5
The MCA has assessed future business value of
the applications and included this in the
systems/applications asset register :
- Functional percentage utilization
- % link to business objectives
- Business priorities support
- Legislative and political support (does it
support political or legislative
requirements).
- Enhanced service delivery.(expected to enhance
the current delivery of services to customers).
- Future measurable benefits. ( expected to
provide additional realizable benefits in the
future).
- Future risk reduction. (contribute to the
reduction of business risks).
- Future organisational innovation, (change and
growth enables individuals or business units to
quickly respond to opportunities, changes in the
operating environment and the changing needs
of stakeholders).
- Future fiscal benefit.( expected to increase
revenue or reduce operating costs in the future).
6 The systems/applications asset register has a report

on the condition of the applications in terms of:
- :
(supports organisational architecture
principles, policies, positions and
standards.
www.icta.go.ke
-
: supports GEA
architecture principles, policies, positions and
standards.
- : level of integration with existing
systems
- Authentication: type and level of
authentication for access and if there is an
audit capability being used
- : Some skills available.
Documentation OK. If applicable, some
compliance with corporate coding
standards. Partially automated
scheduled deployment
- : L o o s e ly c o u ple d with
supporting technologies. All or nearly all
application components can easily be
deployed in another technology
environment or Tightly coupled with
supporting technologies. Deploying in
another technology environment
extremely difficult.
- level at which it can easily
accommodate heavier loads i.e. new users
and/or new sites.(e.g. Requires total or highly
significant investment or Heavier loads i.e.
new users and/or new sites can be
accommodated to a certain degree or Can
easily accommodate heavier loads i.e. new
users and/or new sites or Requires little or no
significant investment or threshold
limitations lead to
performance degradation).
www.icta.go.ke
- level of Reliability (e.g. Very
unreliable -often down or causes data
errors. Availability < 95%, Crashes
regularly, Reliable and small outages for
maintenance. 99.9% or better.)
-
: Occasional performance issues.
- : How it is Users avoid it whenever
they can. Difficult to use. High number of
calls for help from users. Requires
significant training. Easy to use. Few calls
for help from users. Requires minimal
training. Help easily accessible.
7 - For each purchased software, the MCA has

documented an agreed business case
The MCA has documented evidence that they have

8 - conducted a basic review of similar applications
within Government to ensure an alternative
product does not exist that would better meet the
needs? If yes, the list of the names of the
alternative products or services that have been
considered is available.
9 - The MCA has documented evidence that the

software has been tested and meets user
requirements
10 -
The MCA has documented evidence that the
software integrates seamlessly with existing
systems
www.icta.go.ke
- The MCA has documented changes and
11
modifications to the systems
12 - The MCA has documented evidence that t h e

software meets the security
requirements.
13 - The MCA has documented and followed t h e

SDLC software development
methodology for the developed and
customized applications and software as per
the standards.
14 The MCA has a policy that guides software

disposal. The policy shall stipulate that:-
- Disposal of software shall only take place when

it is formally agreed that the software is no longer
required and its associated data files which may
be archived won't require restoration at a future
point in time.
- Any GoK information processing equipment that

is to be disposed of or re-used shall undergo a
cleansing process before release.
- The cleansing process shall consist of

destruction of the licensed software residing on
the equipment, testing and validation of the
process to ensure no software is left on the
equipment.
- Media which are marked as containing highly

sensitive information shall be physically
destroyed
www.icta.go.ke
The MCA has for each system
a. Project initiation documentation detailing the
business case
b. Feasibility study detailing the proposed
solution
c. Detailed user and technical requirements
d. High level and detailed system design
documents
e. System testing and commissioning
documentation
f. Evidence of user and technical training
g. User and technical manuals
h. Certificate of completion
14 The MCA has deployed E-mail and collaboration

tools for official communication for all staff
15 · The corporate email software solution

provide for:-
- Sending of group emails
- Creation of mailing lists from the server. -
Email search and retrieve.
- Creation of email folders.
- Email archiving.
- Scalability- to cater for growing number of
users.
- Global address book for all registered
users.
- Sending email attachments of at least
5MB.
- Appending of a Digital Signature.
- Formatting of e-mail messages (Text
formatting, appending of graphics).
www.icta.go.ke
- Email Account management.
- Security; Real-time spam and Junk mail
filtering, password management and
client/server system patching
- Adequate disk quota for all email users.
- Back up of user mailboxes.
- Push to email support for mobile devices.
- The protocols that shall be supported
by email solutions acquired by MDA‟ s
shall include but not limited to SMTP,
MIME, POP3, IMAP4, LDAP version 3, ,
SSL , TLS and Secure MIME.
The MCA has an Internet and electronic mail

Use of Internet and 17
Electronic Mail Policy policy
and Principles
18 The policy is reviewed on an ongoing basis, is
readily accessible and regularly communicated
to all employees
19 MCA has evidence that employees are trained

in policies and procedures regarding e-mail use
and management.
The policy defines:

20
- which employees within the MCA are
authorized to use Internet and email, and
the conditions and constraints relating to
their use in terms of MCA security, privacy,
copyright, confidentiality and delegation
policies;
- Defines what Internet and email will be
monitored and the conditions under which
this monitoring will take place;
-
www.icta.go.ke 90
- Defines what is considered authorized and
unauthorized use and provide clear
definitions, comprehensive examples and
permitted levels of such use;
- Defines the responsibilities of employees
- Defines E-mail retention periods and archiving
procedures
- Defines security procedures for maintaining
confidentiality, availability and integrity of E-mail
government records
- Define the range of disciplinary procedures and
penalties which may be applied as a
consequence of unauthorized use of Internet
and email including that the penalty in the case
of an employee being found to h a v e
intentionally accessed, downloaded, stored
or distributed pornography using government-
owned ICT facilities and devices is, subject to
industrial and procedural fairness, termination
of employment; and
- Defines who has access to monitoring reports
and the delegation chain of authority for dealing
with reports generated from this activity.
- Defines procedures for termination of an
employee's e-mail account upon his/her departure
- Defines maximum mail capacity
- Defines maximum E-mail sending capacity
21 All devices used for email communication are

encrypted
The email server is hosted in a secure part of the

22 network
23 The email server is regularly backed up
24 There is a report on penetration testing done on the

E-mail server
www.icta.go.ke
25 All staff are facilitated with an E-mail account
26 Is the email account composed of first name and

last name e.g. Firstname.Lastname@xxxx.go.ke
There is a designated staff at the MCA for setting

27 up email
There is a disclaimer for email and messages

specific to the MCA
28
There is an email set up time service level

29 agreement
Digitial signing has been set up for email

30 communication
Email systems are password protected?

31
Email system passwords expire in 90 days and
32 prompt the user to change
Email accessing computers and laptops are set to

33 idle/timeout after 10 minutes?
The MCA has a requisition system put in place where

34 staff can book the facility through a password
enabled system.
There is an approver to give go ahead on who can

35 use these facility and at what time.
There is a monitoring system in place

36
37 A not more than 2 years risk assessment has been

conducted and the report contains:
- Impact on employee productivity
- Network bandwidth requirements and impacts
- Reputational risk to personnel, the MCA, and the
Government
www.icta.go.ke
- Potential avenue for exposure or leakage of
sensitive or protected information such as
copyrighted material, intellectual property,
personally identifying information, etc; and
- Potential avenue for malware introduction
into the organization's IT environment.
- The potential use of “other than
government” sections of Social Media web sites.
The MCA has an acceptable use policy on social

38 media as per the guidelines in the standard
39 Employees have signed consent forms to adhere to

the policy
40 The ICT administrator controls social media usage

as per the acceptable use policy
41 There's a department that manages MCA presence

on social media.
42 Collaboration systems acquired by an MCA:-

Support Features such as email messaging, IP
telephony, instant messaging, personal voice
service, conference call services, data
conference services, document and file sharing,
collaborative document and - file
sharing, forums, data conferencing (sharing of a
white board), short message service, chat, internal
bulletin, address book, video and single sign-on.
- Integrate with existing directory systems for
access to contact information.
- Enable grouping of users.
- Enable a single sign on to all the services.
- Provide electronic group calendaring and
scheduling.
- Project management systems to schedule, track
and charts step in a project as it is being
completed.
www.icta.go.ke
- Workflow systems to manage the
collaborative flow of documents and tasks.
- Intranet portal integration.
- Support different client operating platforms.
- Support common standards for
interoperability with collaboration systems in other
MCAs.
- Support email push to mobile devices.
43 The collaboration tools conform to the following as

per the standards:
a. Ease of use
b. Agility
c. Scalability
d. Adaptable contexts
e. Low, flexible pricing
f. Support
44 There is an acceptable use policy for

collaboration
47 The MCA has an interactive website for

information and services
48 The MCA has the right domain name as per its type
of organization
49 The domain name does not :

- Have a personal name;
- does not exceed 40 characters in length,
including the first, second and top levels of the
domain name
- consist entirely of numerals;
- have the same name as an already registered
entity;
www.icta.go.ke
- express a political statement or bear any
semantic connection to a registered political
party;
- contain obscene or offensive language or
otherwise prejudice the reputation or credibility
of the gov.ke domain;
- Infringe the intellectual property rights of other
parties. It is the responsibility of the Registrant to
ensure compliance with this requirement.
50 Domain names that comprise common words conform

to the correct English/ Kiswahili spelling, grammar
and syntax
51 The Technical composition of domain names is:

i. be at least 2 characters long;
ii. short and simple
iii. easy to say
iv. easy to memorise
v. easy to spell and type
vi. stable i.e. no need to change if the structure of
the MDA's changes
vi. Contain only letters (a-z), numbers (0-9) and
hyphens (-), or a combination of these but cannot
start or end with a hyphen. Only one hyphen is
allowed, start and end with a number or a letter,
not a hyphen.
52 There is a Web Technical Committee with the

following membership:
i. Head of ICT (Chair)
ii. Editorial Chief (Secretary)
iii. ICT Security Representative
iv. Web Master
v. Web Administrator
www.icta.go.ke
vi. ICT Networking Representative
vii. ICT Database Representative
viii. Information Representative
The committee has documented responsibilities as
per the standard
ix. There is evidence that the committee meets
not less than once per month
53 There is a web management committee with the

following composition
i. Head of Communication (Chair)
ii. Head of ICT (Secretary)
iii. Head of each line function in the MCA
54 The committee has documented responsibilities as

per the standard
55 There is evidence that the committee meets not less

than once per quarter
56 The web pages are viewable in standard compatible

web browsers, various operating systems such as
Windows, Macintosh and Linux and devices such as
PC, PDA, tablets, digital TV's and mobile phone based
on the latest web standards.
57 MCA websites shall validate to following (or later)

technologies for published grammars:
a) HTML 4.01
b) XHTML 1.0
58 Web pages and Web feeds are encoded in UTF-8 (UCS

Transformation Format 8) character code
The MCA website is registered in the .go.ke domain

59
60 The website contain the following mandatory elements;

a. Website Banner which contains among other;-
Coat of Arms or MCA LOGO
www.icta.go.ke
where applicable, MCA name, and colors of
national flag where applicable.
b. About the MCA, and links to that shall
contain among other(where
applicable):-
i. Organizational set-up
ii. Role and Functions (Mission, Vision,
Mandate)
iii. Major projects and Schemes
iv. Public Services
v. Publications e.g. Annual reports, strategy
documents, portfolio budget statements
i. Customer Service Charter
ii. Government Tenders
iii. Press Releases / Announcements
iv. Associated Organizations (Related Links)
a. Contact Addresses / Telephone Number /
Email of the Senior Officers and Important
Functionaries of the Ministry/Department
b. A feedback/comment page and FAQS
c. Search Engine
d. Site Map
61 There is evidence that the design of the website or

Web application is regularly evaluated and
improved through usability testing, such as
observing users completing tasks, throughout its
life cycle.
62 There is a report that the Websites is validated and

tested with both automatic tools and human review.
63 Users using assistive technology can complete and

submit online forms.
64 To aid those using assistive technologies, provide

a means for users to skip repetitive navigation links.
Web pages do not have flashing

65 lights/banners and do not cause screen to flicker
www.icta.go.ke
66 Placement and precise measurement of the main
elements of the page such as the banner, coat of arms,
and primary menu are precise and conform to the
official graphic design template;
67 The landing page has an index that links the page

to specialized pages which have been organized to
provide for the specific needs of c i t i z e n s ( G 4 C ) ,
Businesses (G4B) and
Government cross-MCA interaction where
necessary (G2G).
68 Microsites and Intranets follow the same branding

guidelines.
69 The website is formal, clear and readable. Sans serif

fonts with clean lines are preferred. Only one font is
used throughout but not more than three fonts are
used.
70 Website only link to approved public digital assets and

approved social media.
Active and read links are marked through a standard

71
colour-coding convention
72 The correct branded logo or handle for the specific

social medium is used at all times
73 Website only link to its associated social platform
74 Content, breaking news and feedback are regularly

updated on the social platform.
75 There is a moderator with the responsibility to

monitor and moderate social media
conversations and perform quality control.
76 Sharply-focused photographs of reasonable

pixel strength are used;
77
Tools to optimize their file size to its lowest possible
value;
78 They are captioned with a description of their date,

location, event, persons present and
www.icta.go.ke
photographer;
79 The photographs enhance the text not dominate

them
80 The web page takes between 3 and 18 seconds to load.
The website is ranked highly by search engines and

81 appears first on search lists for relevant web searches
82 The website is hosted in a secure location that

conforms to Government of Kenya security standards
to protect the Government from the embarrassment
of a defaced public website .
83 If you are hosting a web-based application which
accesses public data you must ensure that the
database is isolated from the website and fully secured.
84 Always inform a user when and why you are using a
cookie to gather information about her.
85 The website CMS is regularly updated
86 Website is regularly scanned for vulnerabilities and

action taken in any.
87 The web master/web management committee tracks
how many users have the key/root password and
adhere to other security requirement for applications.
88 The copyright of all content displayed on a

website is visually acknowledged.
89 The conditions for use of Government of Kenya
copyright materials displayed on the website is be
stated at a suitable location on the website
90 Keep a record of information on the site by

backing up the site on regular basis
www.icta.go.ke
91 The website has a color code assigned by ICT
Authority
92 Every image, video file, audio file, plug-in, etc. has

an alt tag
93 Complex graphics are accompanied by detailed text
descriptions
94 The alt descriptions describe the purpose of the
objects
95 If an image is also used as a link, the alt tag
describes the graphic and the link destination
96 Decorative graphics with no other function have
empty alt descriptions (alt= "")
97 Captions are added to videos
98 Audio descriptions are added
99 Text transcript are created
100 A link to the video is created rather than
embedding it into web pages
101 A link is added to the media player download
102 An additional link is added to the text transcript
103 The page provides alternative links to the Image Map
104 The <area> tags contains an attribute

105 Data tables have the column and row headers
appropriately identified (using the <th> tag)
106 Tables used strictly for layout purposes do NOT
have header rows or columns
107 Table cells are associated with the appropriate
headers (e.g. with the id, headers, scope and/or axis
HTML attributes)
108 The page does not contain repeatedly flashing
images
109 The page does not contain a strobe effect
110 A link is provided to a disability-accessible page
where the plug-in can be downloaded
www.icta.go.ke
111 All Java applets, scripts and plug-ins
(including Acrobat PDF files and
PowerPoint files, etc.) and the content
within them are accessible to assistive
technologies, or else an alternative means
of accessing equivalent content is provided
112 When form controls are text input fields the

LABEL element is used
113 When text is not available the title
attribute is used
114 Any special instructions are included
within field labels
115 Form fields are in a logical tab order
116 ‘Skip Navigation' button is added to help
those using text readers
www.icta.go.ke
Appendix 2: SDLC PHASES
www.icta.go.ke 102
APPENDIX 3: SDLC ACTIVITIES AND OUTPUTS
NO. PHASE ACTIVITIES OUTPUT/DELIVERABLE
1. PROJECT 1. Collection of information to 1. Scope of the project prior to
DEFINITION determine if a project committing funding and resources,
warrants the investment of including the project timetable with
personnel resources and milestone dates and resource
funding. estimates, and a formalized
approval/authorization or disapproval
of the project based on the project
definition.
2. Identify the customer, user,
mandate, and basic operating
concept.
3. Identification of the program and
project manager as well as projected
costs for training and sustaining
efforts after the project is completed.
4. Preliminary risk analysis and high
level cost- benefit analysis to
determine if the project has a
favorable return on investment
2. USER 1. Review user requests 1. User requirements that clearly

REQUIREMENTS
DEFINITION 2. Meet with users to clarify describe what part of the user
requests process (activity) should be
3. Modify request automated or enhanced, and the
requirements expected capabilities and
4. User approval of features.
requirements 2. The key output of this phase is a
summary document of user
requirements that explains
what the system is supposed to do
5. Explicit written User approval
6. Explicit written User approval or

requirements
www.icta.go.ke
3 HIGH LEVEL 1. Research and 1. The key output of this phase is a
ANALYSIS AND documentation summary document of
DESIGN 2. Review high level analysis system/data requirements that
and design document with explains what the system should
sponsors be built to, how data should be
processed, and what technical or
support requirements may exist.
In addition, security and internal
control related requirements are
also developed as appropriate to
the scope of the project.
2. Explicit written sponsor
approval of agreed upon
solution
3. Resources assigned to project
by sponsor
DETAILED 1. The analysis and design phase 1. The recommendation of what to

ANALYSIS AND is a complex and critical step do or buy in order to meet the
DESIGN in determining which system user and system requirements.
design, based on systems 2. Detailed analysis and design
engineering and technology document approval
analysis, meets the user and 3. Preliminary implementation
system requirements. plan
2. For non-technical solutions, 4. Detailed specifications
the design may simply be a approval
support process to be
implemented over time
3. The design may be
presented as several
options with trade-off
analysis or a specific
www.icta.go.ke
SYSTEM 1. Create test scripts 1. Functioning Prototype
BUILD/PROTOTYPE/BUILD 2. Coding 2. Updated system test plan
3. Unit test 3. Preliminary implementation
4. Verification, validation plan
and testing 4. Unit level test scripts with unit
5. Code review tests results documented
6. Update system test
plan
TESTING 1. Completed system test
1. System Testing 2. Test scripts with system testing
2. Integrated systems results documented
testing 3. Completed integrated
3. User Acceptance systems test
4. Pilot testing 4. Test scripts with integrated
5. Finalize system testing results
implementation plan documented
5. Explicit written Sponsor and
User Group approval of system
test results (approval template
available)
6. Test scripts with user
acceptance testing results
documented
7. Functioning application in
pilot environment
IMPLEMENTATION AND 1. procure, receive, 1. Successful transition to the

TRAINING configure, and install new system without service
the new or revised interruption
system
2. Training according to
the training plan 3.
Documentation 4.
User acceptance 5.
Stakeholder
www.icta.go.ke
POST 1. Periodic reviews 1. Written sponsor approval
IMPLEMENTATION 2. Maintenance and 2. Closed request
enhancements
3. Security evaluations 4.
Setting KPI
5. Continous improvement
6. Quality assurance and
user satisfaction
www.icta.go.ke
APPENDIX 4: MANDATORY FUNCTIONALITIES FOR SYSTEMS TESTING
Input data Ensure the validity and integrity of data input to the new systems by:
validation
● Limiting fields to accept specific ranges of data (e.g., defining out of range
values or upper and lower data volume limits);
● Checking for invalid characters in data fields;
● Making key fields mandatory;
● Verifying the plausibility of input data using business rules;
● Protecting against common attacks (e.g., buffer overflows); and
● Using control balances to verify complete input and processing.
Internal Verify that the new systems include audit trails to:
processing
● Detect unauthorized or incorrect changes to information;
● Prevent information from being accidentally overwritten;
● Prevent internal information from being disclosed via Information and

Communications Technology responses;
● Protect against common attacks (e.g., buffer overflows);
● Check the integrity, authenticity or any other security feature of data or

software downloaded or uploaded between central or remote computers;
● Maintain audit trails; and
● Provide error and exception reports.
Message Determine message integrity requirements during the requirements definition

integrity phase of system development or acquisition to prevent errors, loss, unauthorized
modification or misuse of information in Information and Communications
Technology.
www.icta.go.ke
Output data Verify that processes are documented to validate the data output from
validation systems by:
● Reconciling control balances to verify that data is processed

accurately;
● Verifying the plausibility of output data using business rules;
● Providing sufficient information for a reader or subsequent Information

and Communications Technology to determine the accuracy,
completeness, precision and classification of the information;
● Maintaining audit trails; and
● Providing error and exception reports
Minimum ●When software is designed to run on a system that has a keyboard,

software product functions shall be executable from a keyboard where the function
applications itself or the result of performing a function can be discerned textually.
and operating
●Applications shall not disrupt or disable activated features of other
system features
products that are identified as accessibility features, where those features
are developed and documented according to industry standards.
●Applications also shall not disrupt or disable activated features of any

operating system that are identified as accessibility features wh ere the
application programming interface for those accessibility features has
been documented by the manufacturer of the operating system and is
available to the product developer.
●Software testing The use of live data for testing new system or system
c hanges shall only be permitted where adequate controls for the integrity
and security of the data are in place.
● New systems shall be tested for capacity, peak loading and stress
testing. They shall demonstrate a level of performance and resilience
which me ets or exceeds the technical and business needs and
requirements of the Company.
● Normal system testing methods shall incorporate a period of parallel

running prior to the new or amended system being acceptable for use in
the live environment.
www.icta.go.ke 108
Appendix 5: RECOMMENDED SOFTWARE
The latest stable versions of office productivity suites shall be installed in user computers
Security and software updates are made as soon as they are released.
Where a previous version is to be used adequate justifications are to be provided.
Users shall be adequately trained on the use of any office productivity suites purchased
All office productivity suites acquired is adequately supported and maintained by the vendor.
MDAs shall ensure that all computers and servers are installed the minimum utility software. These
include and are not limited to
- Disk Defragmenters
- Registry Cleaners
- Backup Utility Software
- Data Recovery
- Antivirus Utility Software
To adequately cater for their security requirements, MCAs shall implement security software deemed
appropriate from the following proffered set:
- Endpoint protection systems (AntiVirus, AntiMalware)
- Firewalls/intrusion detection & prevention systems
- Identity and access management systems
- Physical surveillance & monitoring systems
- Encryption systems
- Enterprise information security management
- Network service management systems
- Security auditing, assessment and remediation systems
- Privacy monitoring systems
- Disk storage, recovery, and anti-forensic systems
- Digital forensics systems
- Penetration and fuzzers
www.icta.go.ke
MDAs shall ensure that all database software has and is not limited to the following features:
1. Scalable; to accommodate the growing number of transactions.
2. Data visualization; the software should enable one to analyze data and information graphically of in
raw streams.
3. Performance; the database software should be able to efficiently utilize just about any reasonable
hardware platform on which it runs. It should also be able to manage multiple high - speed
processors, clustered servers, high bandwidth connectivity and fault tolerant storage technology.
4. Reporting; the database software should be able to modify existing reports and create new custom
reports on an ad-hoc basis to meet specific organizational management information needs both in
the present and in the future.
5. Extensibility; the database software should support extensibility to accommodate any
necessary changes to the system in the future.
MCAs shall ensure that all corporate email software solutions acquired provide for: -
1. Sending of group emails
● Creation of mailing lists from the server.
● Email search and retrieve.
● Creation of email folders.
● Email archiving.
2. Global address book for all registered users.
3. Sending email attachments of at least 5MB.
4. Appending of a Digital Signature.
5. Formatting of e-mail messages (Text formatting, appending of graphics).
6. Email Account management.
7. Security; Real-time spam and Junk mail filtering, password management and client/server
system patching
8. Adequate disk quota for all email users.
www.icta.go.ke
9. Back up of user mailboxes.
10. Push to email support for mobile devices.
11. The protocols that shall be supported by email solutions acquired by MDAs shall include but not limited
to SMTP, MIME, POP3, IMAP4, LDAP version 3, , SSL , TLS and Secure MIME.
12. Scalability
13. Compatibility
14. Ensure that the server is protected with a firewall and Antivirus so ftware is installed and regularly
updated.
15. Email transmission is secured through the use of encryption technology such as SSL or TLS among
others.
Collaboration Systems acquired by an MCA shall:-
1. Support Features such as email messaging, IP telephony, instant messaging, personal voice service,
conference call services, data conference services, document and file sharing, collaborative document
and file sharing, forums, data conferencing (sharing of a white board), short message service, chat,
internal bulletin, address book, video and single sign -on.
2. Integrate with existing directory systems for access to contact information.
3. Enable grouping of users.
4. Enable a single sign on to all the services.
5. Provide electronic group calendaring and scheduling.
6. Project management systems to schedule, track and charts step in a project as it is being
completed.
7. Workflow systems to manage the collaborative flow of documents and tasks.
8. Intranet portal integration.
9. Support different client operating platforms.
10. Support common standards for interoperability with collaboration systems in other MDAs.
11. Support email push to mobile devices.

The software shall support standards related to all its components which include and are not limited
to:
- Email- SMTP, IMAP4, POP3 - Encryption- SSL, TLS, S/MIME
- VOIP- RTP, SIP, H323
- Video conferencing –H323 or H320
- Directory- LDAP.
www.icta.go.ke
5.7 Voice over Internet Protocol
To ensure compatibility and interoperability, MCA� s shall ensure that all VOIP equipment shall
employ adopt commonly used protocols standards which include;
● H.323 or the Session Initiation Protocol (SIP) signaling protocols that sets up, maintain
and terminate a VoIP call.
● Media Gateway Control Protocol (MGCP) that provides a s ignaling and control protocol
between VoIP gateways and traditional PSTN (Public Switched Telephone Network)
gateways.
MDA shall ensure that all VOIP communications and systems are secured by ensuring:
● H.323 protocol is secured by using TLS and S/MIME e ncryption for SIP.
● Adequate physical security is in place to restrict access to key VoIP servers and
components.
● Firewalls designed for VOIP protocols are employed to secure the VOIP systems.
● VOIP Terminals are secured through password authentication an d user authorization.
User accounts shall be administered and managed by the ICT units.
● WiFi Protected Access (WPA) where mobile units are to be integrated with the VOIP
system.
● Disabling of HTTP and Telnet services
● Where soft phones are used, PCs should be adequately secured to protect from
worms, viruses, and other malicious software.
● Creating awareness to users on how to secure use VOIP systems.
MCA� s shall ensure where possible that end-to-end encryption of the VoIP conversations is
employed.
VoIP Services must ensure Quality of Service to maintain the sound quality of conventional
phones.
ICT units shall document and maintain an inventory of authorized VoIP instruments and shall
ensure that the VoIP systems only register and use authorized term inals. To avoid use of VOIP
facilities by unknown terminals or PCs, MCA� s are advised to employ use of device
authentication through the use of MAC address.
Where possible, MCA� s shall endeavor to separate voice and data traffic logically on the
network due to bandwidth, security and Quality of service requirement of VOIP. 47
www.icta.go.ke 112
VoIP software should provide for:-
● Traditional calling features including call by name, caller ID, last number redial, hold, call
waiting, call forwarding , transfer, divert, park, retrieve, v oice mail, return call and call
conferencing
● Call Coverage Make it easy to ensure that important calls are answered by
administrative assistants or team members, via user -controlled Delegation and Team
Calling respectively.
● Telephone Directory.
● Maintain Call history.
●Local Number portability, that is, ability to maintain phone numbers when one changes
service provides.
Protocols that are supported include:-
● Real- Time Transport Protocol.
● Session Initiation Protocol.
● ITU-T H.323
● Media Gateway control protocol
● IPSec, TLS and S/MIME for encryption.
5.8 Teleconferencing and Videoconferencing
Mobile Automatic filters-To sort inbound messages into appropriate response categories to
ensure that text messages that are received are acknowledged in some form.
● Address Book- store names, mobile numbers and notes. The database shall reside behind a
highly secure firewall. Message History with status reports –keep a log messages and their
status.
● Group Messaging - The software should setup of groups in the addre ss book and enable
sending of SMS to everyone in that group messages
● Report- The software should enable creation of reports and export to other
documentations software’s for report creation
● Support for traffic limitations and throttling

● Bulk Messaging - This feature allows you to send an individual message to multiple
● Purge Failed Numbers- Allow MDAs to purge numbers based on a chosen number of
consecutive SMS delivery failures.
www.icta.go.ke
113
● Scheduling- Allows MDAs to send out the messages at a chosen date and time. Setup
recurring and automated messages to be sent out at certain days and times of the
week, month, or year
● Compatibility Support for all Messaging to all Phone Models.
● multi-part messages- to allow messages longer than 160 charact ers

● Support for Unicode- To support extended characters that are not supported by your native
character set
● Support for WAP Push messages and Flash
● Central content library
● Centralized management of the entire video conferencing network; incl uding statistics,
directories, and software updates for the system.
● End- to-end management for video conferencing endpoints and infrastructure; managing
endpoints, Multiple Control Units, video and recording solutions, gatekeepers and
gateways
● Should provide for ad hoc and scheduled meetings and conferences.
● integration with email and collaboration systems to schedule meetings and conference
data.
● Enable for Dial in and meet me meetings.
Moderator facility for video conferences
5.9 Network Management Software
MCA’s should ensure that network management software acquired should be able provide the
following but not limited to this features
Discover network components such as devices and links.
Support Layer 2 and Layer 3 discovery.
Generate a layout of the existing network.
Report failures and events.
www.icta.go.ke 114
MCAs shall use Bandwidth management software to optimize the bandwidth that carries t raffic over
networks.
Bandwidth or the amount of data transferred over a communication channel in a specific amount of
time shall be controlled by bandwidth management tools, or traffic or packet shapers.
These tools shall enable network managers to control communications by allowing high-priority traffic to
utilize more bandwidth than something given a lower priority status as well as enable them identify
network traffic patterns, establish priorities, optimize application performance, and allocate resources.
As the number of Internet users shall continue to increase and demand for media -rich and peer- to-peer
applications rises, bandwidth management shall continue to play a role in network management.
MDAs shall use Network management software to manage their internal networks.
This software shall continuously monitor performance, events and faults. MDAs shall ensure that all
Networks monitoring software can produce regular and customized reports.
www.icta.go.ke
Appendix 6: Email etiquette
1 Check the address Double-check the recipient’s e-mail address; you
don’t want to send your e -mail to the wrong person,
especially if you are sending important, private or
sensitive e-mails.
2 Fill in the subject box E-mails without a subject heading are often ignored as
unimportant or deleted as junk mail.
3 Use the BCC function When you are sending information to a large number
of people, use the BCC function. It sends the e -mail
out to each recipient individually. The only other e -
mail address that will appear in the recipient’s
mailbox is that of the sender.
4 Do you need to send an An enormous amount of time and energy is wasted by
attachment people struggling with incompatible formats, files that

never arrived, and attachments that got garbled or
stripped off the message. Consider copying the text of
the attached file into the body of the e-mail message.
5 Pause before clicking “Reply To All”:

Pause before clicking “Reply When responding to e-mails, decide if everyone on
To All”: the original list should receive, or would welcome, your
feedback. If you can make a useful contribution to a
discussion, then do, otherwise, do not get involved.
6 Your response should be first: If you respond to an e-mail and want to include text
from the original e-mail, make sure that your response
is at the top of the e-mail being sent.
7 Consider file size Large files take longer to download, use up space on
e -mail servers and are sometimes undeliverable.
Consider whether images are needed, and if large
files can be compressed.
8 Plain text and HTML do not mix It is best to respond to an e-mail in the format in
which it was received as this ensures that the
recipient will be able to read it. If you respond to a
plain text message by using HTML then the message will
be, at best, difficult to read and often unreadable.
www.icta.go.ke 116
9 Do not use CAPITAL LETTERS If possible, avoid using capital letters, not only are
capital letters difficult to read but they are
associated with shouting and considered rude.
10 Some messages should be Tragic news or an emotional reaction such as anger is
delivered in person handled best in person and not through e -mail. The
problem is that with an e-mail the words are
separated from the physical emotion in your voice
and face — even your body language can speak
volumes.
11 Pause before you hit the send If an e -mail was written in anger, it is best to calm
button down and think before sending it. A problem is best
solved with a clear and calm frame of mind.
12 Personal stationary should not When sending or responding to business e -mail it is
be used for personal e-mail best not to use personal stationary and graphics.
13 Do not forward chain e-mail Chain e -mail is not only tacky, but it is banned from
many corporate networks. Inboxes are already
inundated with chain letters and junk mail, and you
can stop the procession by deleting it upon receipt.
Most Internet Service Providers (ISPs) have some
method of identifying and blocking junk e-mail.
www.icta.go.ke
117
Appendix 7: Critical Systems in Government
No SYSTEM DESCRIPTION
1 IFMIS (Integrated Financial Management System) Integrated Financial
Management Information
System(IFMIS) is an automated
system that enhances efficiency
in planning budgeting,
procurement, expenditure
management and reporting in
the National and County
Governments in Kenya
2
32 E-CITIZEN PLATFORM This is a system for Kenyan
Citizens and Foreign Residents
to apply for Government to
Citizen (G2C) services and pay
via mobile money, debit Cards
and e-Citizen agents.
3
4 IPPD The integrated payroll and
personnel management
database (IPPD) is a system for
managing Government
employee records
4
5 IPRS The Integrated Population
Registration System (IPRS) is an
initiative aimed at
consolidating population
registration information into a
single database for ease of
verification by both
Government and private
bodies.
5
I.D SYSTEM The I.D system at the National
Registration Bureau is used for
secure production and issuance
of secure identification documents,
management of a comprehensive
database of all registered persons
and detection and prevention of
illegal registration.
www.icta.go.ke 118
6 GDC Applications The Government Data Centre
(GDC) is designed for processing
and storage of Government
applications and data.
7 Applications on CCP The County Connectivity project
aims at ensuring that county
government offices are connected
to the internet and promote online
services using telephones, emails
and teleconferencing.
8 E-MAIL This shared service is used for

online communication for all
Government officers
www.icta.go.ke
APPENDIX 8: AUDIT FOR OUTSOURCED DEVELOPMENT
- Appropriate stakeholders are - Budget was properly

involved. determined.
- Project champion represents the - Timeline is realistic

key stakeholders. given project magnitude
and past organizational
- Project is consistent with the
experience.
organization’s strategic plans.
- Appropriate metrics and
reporting schemes are
developed.
- Appropriate stakeholders are - Project plan and budget

represented. remain realistic given
business requirements.
- Security requirements are defined.
- Business requirements
- Automated and manual controls are
do not overly rely on new
considered.
and/or unproven
technologies (e.g., a
requirement that all
transactions will process
over the intranet).
- Technical requirements support the - Project plan and budget

business requirements. remain realistic given
technical
- Members of all impacted technical
requirements.
units represented.
www.icta.go.ke
- Lead times for
- Technology assumptions are properly
purchasing, receiving,
validated through internal experience
installing and testing
or external site visits.
new hardware have
- Links to existing applications are been properly reflected
defined and controlled (e.g., control in the timeline.
totals)
- RFP and vendor assessments come - Vendor contract terms

directly from business and technical are favorable, and
requirements. include clauses on cost
overruns.
- Selected vendor has experience in
your industry, with companies your - Vendor contract
size, and with similar setups. includes
- Vendor is financially stable and will be rewards/penalties for
around for long term support project timeliness.
(alternatively, the source code could

- Project plan
be owned by your appropriately reflects the
organization). resources and time
- Proper change management and necessary to install,code and
security controls are set up for the coding modify.
environment.
- All testing is performed in an - Resolution of test issues is

appropriate environment with focused on items that are
adequate security. n e c e ssa r y t o ac h i e v e
- All issues noted during testing are business or technical
communicated to the proper owner requirements (not all issues
within the project. must be solved prior to going
- Test cases reasonably reflect the live!).
environment as it will appear in - Project plans are properly
production. updated to reflect issues noted
- Change management controls are in in testing that must be
place as system elements progress resolved.
through the testing cycle.
www.icta.go.ke
- Data is accurately mapped from the - Project plans are
old system to the new. properly updated to
reflect issues noted in
- Key data elements are screened using
data conversion that
software (or manually in some cases)
must be resolved.
to ensure anomalies are removed.
- After conversion, sample data

reflects accurate transfer.
- Control totals of key data

fields/tables show consistency in the
old and new data structure.
- Training addresses both system usage - Training and

and business process.
documentation are
- Training includes all affected parties.
properly included in
- Training is provided close enough to
the project plan and
implementation to allow participants best
budget.
retention.
- Documentation (online and paper) is
organized in a way to be useful to users
and operators.
- Promotion to production - Final costs are captured and

environment follows established summarized (watch out for
change management procedures. implementation problems
- Parallel processing with old being defined as “on-going
system(s) commences. maintenance”).
- Help desk and “swat teams” are in place.

- Project teams are closed down
- System backup procedures are as the implementation contin-
established. ues.
www.icta.go.ke

Systems &amp; Applications Standard

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Systems &amp; Applications Standard

Uploaded by

Copyright:

Available Formats

Systems and Applications Standard

First Edition 2016

©ICTA 2016 All rights

©ICT Authority 2016

Document Name: Systems and Applications Standard

In pursuit of achievement of this mandate, the Authority established a Standards Committee to

● Ensure data/ information sharing across Government

● I SO/IEC 12207 Software lifecycle processes

● 15489-1: 2001: Information and documentation –Records management- Part 1 General

● ISO/NP TR 15489-2: Information and documentation –Records management- Part 2

● ISO/TR 15489-2: 2001: Information and documentation –Records management-

● ISO 16175-1:201/2011:formation and documentation -- Principles and functional

● NIST Special Publication 800-45 Version 2

DLC Software Development Lifecycle

- Application and system software acquisition

8.3 Messaging and Collaboration

The aims of the architecture model are:

data modeling interfaces

The enterprise viewpoint for e-government applications Annex A.1

The Application department in ICTA in charge of

This viewpoint determines the structure and semantics Annex A.2

A coherent process definition calls for the use of general

The ICT Authority is a State Corporation under the State Corporations

The engineering viewpoint describes the system support Annex A.4

This viewpoint describes the concrete technologies Annex A.5

Application software, systems software and application Annex B.1

Application software, systems software and Annex B.3

Application software, systems software and application Annex B.4

MCAs shall ensure appropriate acquisition, Annex C.2

MCAs shall ensure appropriate use and management Annex C.3

MCAs shall ensure appropriate use and management Annex C.4

9.4 Websites development management

MCAs shall establish a governance structure to Annex D.1

The ICT Authority is a State Corporation under the State

updated to mitigate any cyber security threat.

stakeholders interested in the site.

Certain organizational requirements must be fulfilled

What is generally needed is co-operation, networking

As far as administrative procedures are concerned,

In order to enable the nation-wide approach cabinet

The successful introduction and implementation of e-

The use and updating of standards means a continuous

The legally binding nature of electronic

E-government offers a host of options and

People with disability (impaired vision and physical

Information primarily covers the provision of

Besides the classification in terms of interaction

This situation refers to the electronic interaction

This term covers electronic relations between

The public administration can be divided into service

Services are demanded, i.e. initiated, by citizens or

The individual transaction types can be broken down

As a precondition for applying for a service, citizens

Finally the decision is communicated to the applicant.

The individual transaction types can be broken down

The analysis of the different roles leads to the need

The actions identified are implemented in the form

The definition of basic modules leads to the

Schemas ensure uniform data grammar, semantics and

The MCDAs are to ensure that common schemas and

ANNEX A.3 Computational viewpoint

The computational viewpoint is introduced in order to

Design decisions for the establishment of a software

The MCDAs are discouraged from implementing

Systems & Applications Standard

Systems & Applications Standard