INTRODUCTION

KRA as the government’s sole revenue collecting agency is mandated to assess, collect and
account for all tax revenues.
The Authority’s 6th Corporate plan outlines the various strategies in tackling critical shortcomings
in service delivery, which includes developing and fostering a collaborative and inclusive service
environment by advancing business process systems to a more front facing customer approach
and integrating back office with front office processes across business anchoring on the corporate
theme of Trust and Facilitation.

The Authority wishes to adequately enhance citizen-centred service delivery and facilitate a
desirable customer experience resulting in continuous satisfaction levels thereby improving the
Authority’s image and enhancing compliance that will lead to increased revenue streams.

The Authority wishes to procure and implement a modernized and efficient Contact Centre, as
well as a Customer Relation Management tool. With these tools the Authority is expecting to:

1. Increase first contact resolution

2. Increase taxpayer service efficiency
3. Increase taxpayer satisfaction and expectations
4. Increase agent and the Authority’s efficiency
5. Reduce the operational cost
6. Increase taxpayer satisfaction

CALL MANAGEMENT SYSTEM EXPECTATIONS

1. Optimize call routing and matching to the available resources

2. Improved management of call volumes.
3. Enriched taxpayer engagement with real-time information
4. Enhanced workforce management
5. Improved service level and performance management.
6. Prompt and effecting reporting on dashboards and trends.

CUSTOMER RELATIONSHIP MANAGEMENT (CRM) SYSTEM EXPECTATIONS

1. Improved management of multiplicity of Communication Channels

2. Effortless taxpayer Self Service Support
3. Efficient logging of service requests
4. Improved knowledge sharing across the Authority and with taxpayers.
5. Improved analytics and reporting.
6. Deliver single point of access to other business systems (Integration with the business
systems)
7. Creation of personalized and targeted services based on taxpayer’s needs and preferences.
8. Improved tracking and measurement of customer requests, incidents and fulfillment.

1
 TECHNICAL SPECIFICATIONS
GENERAL INFORMATION
1.0 Technical Requirements:
1.1 Technical Response
Bidders shall provide detailed responses to demonstrate how their proposed solution will
achieve each of the functional capabilities for all the Technical Requirements. Failure to
conform to these conditions will render the bid being treated as non-responsive. Simple
statements such as “yes”, “no”, “comply” or any other similar statements will not be
considered as a substantial response.
1.2 Proposed Implementation Approach, Methodology and Work Plan
Bidders are required to describe their technical approach and methodology to deliver
this assignment, to realize the expected output.

Bidders to propose a methodology and approach that will be employed.

Further, Bidders should provide costs of implementing each module and their
recommended priority order of implementation, taking into account the following
KRA’s priority areas:
Customer Relationship Management
• Customer Service Module
• Multiplicity of communication channels (Omni-Channel Support)
• Unified Messaging
• Web Customer Service
• Interaction Management
• Knowledge Management
• Marketing Component
• Workflow Management
• Integration with
• Reporting and Analytics

The priority order of phased implementation will however be agreed upon between the
successful Bidder and the Authority.
2.0 Place of Execution
2.1 Place of Execution shall be: Nairobi, Kenya
5.0 COMPLIANCE MATRIX SCORES
The compliance matrix scores are given as follows:
Section A: Scope and Implementation Approach – 5 %
Section B: Functional Requirements – 30 %
Section C: Technology Requirements – 10 %
Section D: Service Level Agreement (SLA) and Support Requirements – 5% Marks
Section E: Training and Skills Transfer – 5 %
Section F: Security Requirements (5 %)

2
3
4
 CUSTOMER RELATIONSHIP MANAGEMENT
SOLUTION
SECTION A: SCOPE AND IMPLEMENTATION APPROACH (5 %)
Item Feature Bidder’s Max
No detailed Score
Response
1.1 Functional Areas of Implementation 2
The functionality scope should cover the following main modules:

Customer Relationship Management (CRM) Solution

• Customer Service Module
• Omni-channel support
• Social Media Integration
• Unified Messaging
• Web-customer service
• Interaction Management
• Knowledge Management
• Workflow Management
• Virtual Assistant
• Performance Dashboards (Real-Time & Historical Statistics)
• Marketing Module
• Lead Management
• Reporting & Analytics
Minimum functional requirements are provided under Section B
below.

1.2 Solutions Integration Requirements 1

Detailed areas of integration to systems will be determined in the pre-
implementation workshop, however, the proposed solution must
integrate with the following:
• Contact Centre Management solution
• Social Media Management Module
• iTax System
• iCMS System

1.3 Implementation Methodology 2

▪ Bidders to provide a detailed implementation approach
▪ KRA’s priority areas as shall be determined during the pre-
implementation workshop

5
 SECTION B: FUNCTIONAL SPECIFICATIONS (30%)

Bidders
Max
Minimum Specs detailed
Score
response
Customer Service Module
1.0 General Requirements 4
The bidder will provide detailed information about
Service on multiplicity of communication channels as
follows
1.1 • Unified Desktop: The ability of the system to 1
integrate applications to a single desktop

• Mobile Desktop: The capability of the system to be 1

accessed from anywhere (Mobility)
• Case Management: The capability of the system to 1
intelligently route, queue, escalate cases/incidences
• Telephony control: The capability of the system to 1
enable control of a softphone with a computer or vice
versa. All the telephony controls should be rendered
on the CRM platform using CTI.
1.2 Contact Management 19

The bidder shall provide details of how the Solution

captures customer information as follows:
1.2.1 • Management of taxpayer details for a minimum of 2
10million taxpayers (individual & corporations)
Details including:
-Taxpayer name
-Taxpayer identifier
-Address Information
-Contact Details - Email, Fax, Phone, Mobile etc
-Taxpayer Type (trader, student, government etc)
- Social Media Accounts
2
• Ability to set up and maintain data fields e.g. drop
down lists, field protection etc.

• Ability to manage Taxpayer data to prevent duplicates. 2

De-duplication functionality must be provided.

• Bidder to demonstrate the ability of the system to 2

classify taxpayers into categories e.g. medium and
large taxpayers or geographical categorization.
Customer Categorization based on various attributes.

• Ability to designate a Taxpayer to a service zone,

Geographical region, County, Region 1

6
 • Ability to manage multiple contacts and contact types
for a Taxpayer e.g email, phone and other contacts. 1

• Bidder to demonstrate the ability of the system to store

Taxpayers preferred mode of communication 2

• The system should provide both free-text typing and 1

structured forms when capturing issues of the
Customer

1
• Ability to support automatic validation of Taxpayer
fields based on predefined formats

• Ability to support a visual dashboard for agents which 2

will provide relevant summarized Taxpayer
information on one screen.

1
• Ability to create and modify individual and corporate
customer details.

• Ability to search customers’ information by using 2

advanced search criteria e.g PIN. Ticket No.

2.0 Multiplicity of Communication Channels (Omni-channel 18

Management)
2.1 The bidder will provide detailed information about Service on
multiplicity of communication channels as follows
2.1.1 • The solution must support various channels of 3
communication to customers including web,
telephone, social media, email, chat, WhatsApp, SMS
e.t.c

• Ability to track interactions with Customers regardless 2

of the channel that the Customer used to engage with
the Authority
2
• Bidder to demonstrate the ability of the system to
support issue resolution through the use of the short
messaging platform and instant chat

2
• Ability of the system to retain history of the Taxpayer
correspondences and responses. Ability to support
Customer satisfaction trend analysis
2
• Ability to untether desk agents from their work
stations to work from anywhere using any device such
as mobile phones.

7
 2
• Ability to allow taxpayers to access services including
self-service through their mobile devices and web
portal.

• Ability to support web surveys and campaigns e.g.

targeted recurrent, multi-step. (To move to Marketing
Module)

• The campaigns should also be supported in all

channels, email, SMS, voice, social media e.t.c (Move
to Marketing Module)

• Ability of the proposed CRM solution to interface with 3

the Contact Centre system to provide immediate caller
identification and information.

2
• The System should have the full management
functionality of the interaction life cycle, including
contact list management, interaction routing, Real-
time monitoring and historical reporting, Agent
monitoring.

2.2 Marketing Component

The bidder should demonstrate in detail that the
solution has the following capabilities
2.2.1 Landing page builder
2.2.2 Advanced segmentation: unlimited, flexible segmentation
2.2.3 Dynamic customized lead scoring
2.2.4 The capability of the system to send targeted campaigns
2.2.5 The capability of the system to send mass campaigns

Social Media Integration

The system should support the following : 6
2.2.1 • Bidder to demonstrate the ability of the system to
integrate with the corporate Social Media Pages
• Tag outbound and inbound correspondence
• Bulk outbound correspondence
• Automatic load of incoming tweets, tags and queries
etc.
• Automatic processing of incoming tweets, tags and
queries etc.
• Automatic reminders and notifications
2.2.2 Social Monitoring
The system should support 9
• Out-of-the-box integration with social media
platforms such as Facebook and Twitter
8
 • Framework to tap into other social networks such as
blogs

• Automatic distribution or pick up of tweets/posts

• Multiple sessions that agents may handle

• Screen-pop for social media platforms and

functionality

• Use of the knowledge base for standard and edited

posts

• Workflow cases creation to guarantee that posts are

answered

• Built-in contact history available for agents

• Special indicators for monitoring and reporting

3.0 Unified Messaging 15
3.1 Email Support
The proposed solution should have capabilities to
perform the following:
3.1.1 • Email integration to the corporate email system –
Lotus Domino
• Tag outbound emails
• Bulk outbound emails
• Automatic load of incoming email
• Automatic processing of incoming emails
• Spell Checker
• Dictionary
• Email Archiving feature
• Intelligent Email Routing with escalation on non-
response
• Email tracking
• Automatic reminders and notifications
• Auto categorization
• Auto Acknowledgement
• Auto suggestion on typing
• Attachments (inbound/outbound)

3.2 Multimedia Integration 2

• The system should support multimedia integration
• The system should support video/audio collaboration
3.3 Instant Messaging 11
The system should support the following:
• Support web chat
• Alert on a new chat interaction
• Multiple chat sessions.
9
 • Standard chat operations such as: connect,
disconnect, extend, retrieve, transfer and conference
• Support Chat between agent(s) and customers
• Records of chat communications
• Control of window size
• Chat works on all types of pages
• Support various elements of information including
articles, email templates, and quick text documents
• Support message broadcasts
• Support archiving of chats
4.0 Web Customer Service
4.1 Self Service Support 2
The bidder will provide detailed information about Self Service
support as follows:
4.1.1 • The system must support self-service requests based
on a catalogue of services
• The system should allow the requestor to create a
service request based on the catalogue of services

4.2 The bidder will provide detailed information about 8

Web Conferencing support as follows:
4.2.1 • The system should have desktop sharing facility to
allow for desktop sharing
• Integrated Voice: The system should have fully
integrated voice system. The attendees would simply
listen through their computers without using the phone
or any other device.
• Ease of customization: The system should be able to
integrate with website and customizable in terms of
look and feel
• Full reporting: The system should be able to access
reports on attendance, archive views and typed
messages
• Flexible Recording: The system should be capable of
recording and archive presentations.
• Slide Show: The system should have a slide show
function to share presentations
• Configurable Chat: The system should have a
configurable and controllable private chat function
between attendees
• Controllable document sharing: The system should
allow attendees to download files such as brochures,
agendas, presentations and such within the web
conference interface without having to email them.
5.0 INTERACTION MANAGEMENT
The system should have the ability to keep history of
interactions, archive and retrieve interactions:
5.1 Service Requests 12
Service Requests are user needs that are lodged for
resolutions. Service request should be handled in a
structured format and the bidder should provide
detailed information on their capability to handle
service requests.
5.1.1 • Ability to log service request tickets and assign to
specific users or group of user groups
10
 • Ability of the system to send acknowledgements to
Taxpayers in their desired communication channel.
• Ability to reassign service request ticket to a different
user and notify them.
• Ability to define Service Level Agreements (SLA’s)
for various types of service requests and track the
SLAs.
• Ability to escalate a service request if the agreed SLA
has been breached
• Ability to provide service analytics based on defined
SLAs
• Ability of the system to notify users when tasks are
assigned and/ or escalated to them
• Notification to taxpayers when their service request
tickets have been resolved
• Ability of the system to facilitate the creation of
various categories of service requests
(Incident/problem / general request etc)
• Ability to search through requests raised by using
advanced search criteria
• Ability of the system to provide alerts that are
triggered based on service rules e.g. Tax Return filing
due dates
• Ability to provide templates and workflows for
resolution of various types of issues.
6.0 Service Catalogue 32
The bidder will provide detailed information about Service
Catalogue as follows:
6.1.1 • Ability to define a service catalogue of all services that
can be provided to taxpayers
• Ability to define rules to qualify or disqualify taxpayer
for services on the catalogue
• Ability to configure prices for services in the catalogue
• Ability to provide seamless service selection user
interface
• Ability to maintain a log of all actions and updates to
a service request with time and date stamps
• Ability to add, update or delete a service subscription
by a taxpayer
• Ability to update status of the service requests at
various stages
• Ability to automatically launch a workflow for service
request management
• Ability to create tasks and associate them to the
service request
• Ability to notify staff assignees of work assignments
electronically (mails, Short Messaging System (SMS)
• Ability to provide final resolution details of work
orders or service requests.
• Ability to assign a service request to back office or
other departments if the problem/incident occurs
• Ability to assign service requests manually
• Ability to support escalations of service requests and
/or tasks that are not resolved within the stipulated
time

11
 • Ability to support the assignees to update the status of
the task assigned to them including details of time and
materials used
• Ability to support automatic assignment of service
requests to resources based on pre-determined
criteria(s)
• Ability to search and view service requests based on
different criteria
• Ability to link a service request e.g. multiple taxpayer
service request to a single trouble ticket
• Ability to capture a taxpayer request and cascade it to
back office systems for resolution
• The user should be able to set resolution and response
times, service levels, priorities and auto-escalation
parameters of cases/issues/problems or incidences
• The system should be able to enforce response times,
service levels, priorities and auto-escalation
parameters of cases/issues/problems or incidences
• Ability to close and report on service requests
• Ability to bundle service e.g. opening, escalating and
closure of service request defines a resolution time
• Ability to monitor and enforce Service Level
Agreements (SLAs) and Service Contracts
• The system should allow for viewing of all escalations
at individual, departmental and KRA-wide levels
• The system should be able to have configurable and
fully customizable workflows to track activities of all
escalations and route them to relevant actors
• The system should be able to enable users to confirm
and update status of their escalations
• The system should be able to store created and/or
scanned documents with an indexing and meta data to
create searchable content
• The system should have workload reporting
capabilities to allow management to report on
outstanding document actions and tasks
• The system should be able to support document
archiving
• The system must operate in a multi-office organization
format, i.e. system should be accessible to all KRA
stations countrywide.
• Ability to link IVR data fields to service catalogue

7.0 Workflow Management

The system should support: 5

• Alerts on a new task delivery

• Task pick up from pending activities
• Manual assignments of tasks to a specific user or to
specific queues
• Pushing of manual tasks (automatically assigned to
agents) or “pull” (the agent decides what task to
handle and picks it up).
• Automated assignments of tasks to a specific user or
to specific queues.
12
8.0 Reporting Module 8
The bidder will provide detailed information on the Reporting
module as follows:
8.1 • System should have ability to support development of
graphical reports and real time status information.
• Ability of the system to allow users to view historical
reports to help them analyze trends, establish
performance benchmarks, and plan new Customer-
service campaigns
• Ability of the system to perform sentiment analysis on
social media i.e. analyze both positive and negative
posts, comments and tweets
• Ability of the system to carry out traffic analysis on
email, Facebook and Twitter
• Support analytics through role based reporting and
dashboards
• Support analytics through effective utilization of Key
Performance Indicators (KPIs).
• The system should have Real-Time dashboards and
should also be used for data analysis.
• The system should have dashboard drill down
capability from graphs to record level to be able to
perform real time problem solving and analysis of
opportunities for improvement
10.0 Knowledge Management 5

The bidder will provide detailed information on Knowledge

Management as follows:
10.1 • The system should have the capability to support a
knowledge base and provide advanced search
capabilities
• Ability of the system to allow authorized users to write
new knowledge into the knowledge base
• The system should allow the requestor to search for a
solution in the knowledge base e.g. using key words
• Support integrated single knowledge base across all
channels
• Support guided knowledge through content driver
guides
11.0 Integration 8
The bidder will provide detailed information on
Integration functionality as follows:
11.1 • Ability to support multi- site Call Centre
• Support Computer Telephony Integration (CTI) with
the Call Centre System
• Support interaction blending across media types e.g.
moving agents between inbound and outbound emails,
web
• Ability to integrate applications to a single view
(unified desktop)
• Ability to route and queue inbound customer
interactions e.g. emails, social media
• Ability to link IVR data fields to service catalogue
• The system should support secure uploading and
downloading of data.

13
• Ability to integrate and support text, audio and video
communication over the web between the CRM user
and customers.

14
 C. TECHNOLOGY REQUIREMENTS (10 %)

No. Requirement Bidder’s Max

Response Score
1 For Cloud Hosting or/and On-premise hosting 12
Bidder to describe their proposed technical architecture and how the
following shall be realized:
• Provide 24/7 access and support to users
• Commit to 99.99 service availability and ensure Zero (0%) data
loss in the event of any interruption
• Provide secure communication between users and the service
• Support user mobility from anywhere in the country
• Provide customized views for different mobile device.
• Support for users to access the service using mobile devices.
• Support web access to the required service
• Access to security audit trails and other capacity and availability
reports as agreed in SLA’s
• Provide service measurement data, reports, data collection and
analysis, service credits
• The system must be able to support at least 100,000 concurrent
connections scalable
• System must support compression to allow large amounts of data
transfers over any network medium for efficiency and
economizing
• The solution should collect and log application event logs such as
session management failures, solution errors etc
2 Integration 2
The Bidder should propose how the system will support secure
integration between the system and any web-based and database data
sources, using standard method of data interchange e.g. XML, SOAP,
JSON, FTP, SMTP, etc.
3 Security 2
• The system should support secure uploading and downloading of
data.

• Bidders are required to ensure compliance with the KRA ICT

Security requirements in part F. where applicable
4 Back-up and Recovery 2
• Bidder to propose back-up, recovery and continuity plans to ensure
protection against permanent loss of data and extended loss of
access to the solution.
• Provide the ability to download a copy of critical SaaS data and
configurations to store on local servers
5 Licenses
• Bidder to state clearly the licensing regime and subscription terms
of the product, i.e.:
➢ Dynamic Desktop Agent licenses
➢ Knowledgebase Service agent licenses
➢ Content Centre Licenses
➢ Supervisor License
➢ Quality Assurance licenses
➢ etc.

• Bidder shall specify the number of requisite licenses based on the

information below.

15
No. Requirement Bidder’s Max
Response Score
• The licenses shall include: operating systems, application user,
databases, and middleware, where applicable.
• The No. of users are 100 at minimum but scalable
• Bidders to use the above information to determine the optimal
number of licenses required for each of the proposed modules in
the solution.
• The bidder may give any additional information that may be
useful for the provision of the service/product

6 Documentation 3
Bidders shall provide all requisite documentation
including but not limited to the following:
• System Architecture and Design
• User and technical manuals
• Training manuals
7 Installation/Enhancements/Upgrade 4
• Bidder to specify whether the following types of system
implementation tools are provided:
(a) Quick implementation/configuration tools
(b) Development tools (e.g. report writer, screen painter,
programming language, etc.).
(c) Debugging, auditing and testing tools (for both functional and
performance testing)
(d) Provision for remote patch and version administration
• Bidders to specify policy on future upgrades and future product
release. Also explain the product lifecycle management with
product-technology roadmap for a minimum of 3 years.

16
D.SERVICE LEVEL AGREEMENT (SLA) AND SUPPORT REQUIREMENTS –
(LOT I & II) (10 %)

The bidder shall provide an SLA proposal addressing the following requirements

1.0 Service Level Requirements/Targets

1. Short Description and Scope of Service
2. Definition of terms
3. Users of the IT Service – (Users are defined from the functional areas covered by the
scope)
4. Breakdown of the Services offered or Service components, e.g. IT Applications.
5. Warranty of at least one year - period, terms i.e. what is included and what is not included
during the warranty period (labour or service)
6. Support and maintenance after commissioning – period, terms, licensing requirements –
for 3 years (Bidders to cost for each year in the financial proposal)
7. Quality of Service terms
1. Service times
2. Security requirements and compliance
3. Availability targets and commitments

a) Conditions under which the service is considered to be unavailable (e.g. if

the service is offered at several locations)
b) Availability targets (exact definition of how the agreed availability levels
will be calculated, based on agreed service time and downtime)
c) Reliability targets Mean Time Between Failures (MTBF) or Mean Time
Between Service Incidents (MTBSI) optional
d) Maintainability targets Mean Time to Restore Service (MTRS) whenever
there is an incident
e) Down times for maintenance (number of allowed down times, pre-
notification periods) – provide draft proposal
f) Restrictions on maintenance, e.g. allowed maintenance windows, seasonal
restrictions on maintenance, and procedures to announce planned service
interruptions, need to agree on suitable schedule with minimal service
disruptions.
g) Definitions of incidents priority (Critical, High, Medium, Low and
Scheduled) including procedures to announce unplanned service
interruptions - provide draft proposal
h) Service performance reporting and reviews meetings - provide draft
proposal

4. Capacity/ performance targets and commitments - provide draft proposal

i. Required capacity (lower/upper limit) for the service, e.g.

a) Numbers and types of transactions

b) Numbers and types of users
c) Business cycles (daily, weekly) and seasonal variations e.g. on
due dates, end months etc

ii. Required Response times from applications

17
 iii. Incident Response and resolution times to requests by client for support
Priority Definition Response Resolution
time Time
Priority 1 ~ Critical Service Down (all work stops). Response 2 hours.
Impact Immediate
Priority 2 ~ High Impact Group Inoperative (Group work stops) e.g. within 30 4 hours.
Localized Disruption access to multiple locations minutes
Priority 3 ~ Moderate Individual work is stopped within 2 8 hours.
Impact hours

Priority 4 ~ Minimal (Work can continue) e.g. Software functionality within 4 24 hours.
Impact problems hours
Priority 5~ Individual Configuration (work can continue) within 1 day 48 hours.
Scheduled Process e.g. Software upgrades, scheduled computer
replacements/relocations/new installations*. IT
equipment Repair
iv. Requirements for scalability (assumptions for the medium and long-
term increase in workload and service utilization)
v. Requirements regarding capacity and performance reporting

5. Service Continuity commitments (availability of the service in the event of a

disaster)
a) Time within which a defined level of service must be re-established
b) Time within which normal service levels must be restored

2.0 SLAs Components: Services and Management.

Service elements to include as a minimum:

• Specifics of principal services provided (and what's excluded, if there's room for
doubt),
• Conditions of service availability,
• Service/quality standards with turnaround times for delivery
• Legal or other regulations that must be complied with
• Standards such as time window for each level of service (prime time and non-prime
time may have different service levels, for example),
• Roles/responsibilities of each party and contact details,
• Escalation procedures,
• Service credits/penalties
• And cost/service tradeoffs.

Management elements should include as a minimum:

• Definitions of measurement standards and methods - how service will be
measured, monitored and evaluated for service performance – quantitatively and
qualitatively
• Reporting process - how to communicate/report performance – what are the
KPIS/outcomes or impacts
• Contents and frequency,
• a dispute resolution process - how to handle complains or conflict issues
• An indemnification clause protecting the customer from third-party litigation
resulting from service level breaches (this should already be covered in the contract,
however),
• Use problem resolution clauses in a multivendor environment to protect KRA (is
primary vendor responsible?)
• Review meetings – frequency, reports
• A mechanism for reviewing/updating the agreement as required.

18
E. TRAINING AND SKILLS TRANSFER – 5 % ( To be revised)

Item Feature Requirements Bidder’s Max

No. Response Score
1. Technical The bidder is expected to conduct a needs
Skills assessment for the technical skills required to
Assessment successfully implement and sustain the
Contact Centre Management solution & the
Customer Relationship Management
Solution.
2. Methods of The bidder is expected to demonstrate
Training methods of training and skills transfer that
and Skill will ensure that KRA has enough internal
Transfer capacity to maintain and use the two
solutions.
3. Training of Bidders shall propose and provide pre and
users post training and knowledge transfer strategy
with the following :
• Propose/provide
training/accreditation centre
• Proposed/Provide Training
Curriculum to train at minimum:
o 15 Technical IT staff
o 150 users from various
groups (Contact Centre &
Business)
o 20 user support staff.
o 15 Project Staff
• Provide the necessary documentation

4. Training The bidder is expected to provide the trainees

Materials with training material both soft and hard
copies.
5. Training The bidder is expected to provide a
Evaluation methodology of evaluation of the training,
learning and skills transfer
6. Training All trainings must be provided at an
facility accredited centre or laboratory. Bidders shall
propose training site and location.
7. Skills and The bidder MUST provide Skills and
Knowledge Knowledge transfer to the users by the
Transfer completion of the implementation. The
bidder to specify the approach to be used.

19
SECTION F: SECURITY REQUIREMENTS (5 %)
Requirement Bidder’s Response
User Authentication
2.1 The solution should support Multi-factor authentication (MFA)
schemes
2.2 Each user must be authenticated with a unique user-id / username and
password on the application. The User IDs / Usernames should be case
sensitive
2.3 The solution should make a provision for authentication through
digital certificates using Public Key Infrastructure (PKI) under the
National Public Key Infrastructure.
2.4 The authentication should be configurable to use username/password
and multi-factor authentication
2.5 All user accounts must be managed with reference to and in
synchronization with an authoritative central user management system
e.g. identifying personnel numbers in KRA’s active staff database
(Active Directory, Central HR database or the ERP e.t.c.) for internal
KRA users and National PIN database for external KRA users.
NB: User accounts management activities include but not limited to
new user creation, user maintenance, and user authentication (during
login).
2.6 All new users should receive notifications with secure links to register
new accounts. A secure way of confirming a registration should be
implemented e.g. via email
2.7 The solution must prompt users to change their passwords the first
time they log on to the application.
2.8 The solution must support password expiry features with a
configurable frequency. This should be parameterized to allow
flexibility in adjusting this value as required.
2.9 The solution shall allow configuration of account validity period.
2.10 The solution should not support automatic logins. The login page
should include a challenge which the user responds to before
proceeding with the login.
2.11 The solution must implement the following Password complexity
requirements that should be configurable to support future password
complexities:
2.12 Passwords should have configurable minimum and maximum lengths.
2.13 Password must meet a configurable combination of the following 4
complexity rules:
2.13.1 Uppercase character (A-Z)
2.13.2 Lowercase character (a-z)
2.13.3 Digits (0-9)
2.13.4 Special characters
2.14 During password change, if the new password doesn't comply with the
complexity policy, the error message should describe EVERY
complexity rule that the new password does not comply with.
2.15 The solution should implement a secure self-service password
recovery mechanism in the event the user forgot their password.
2.16 Any password reset/recovery mechanism option must not reveal
whether or not an account is valid, preventing username harvesting.
2.17 The login page and all subsequent authenticated pages must be
exclusively accessed over (Transport Layer Security) TLS. All active
sessions must be encrypted.

20
2.18 The solution should support expiring of newly created accounts if not
used for a period of time. This should be parameterized to allow
flexibility in adjusting this value as required.
2.19 The solution must support a configurable password change notification
before password expiry.
2.2 The solution must support password lock out after a configurable
number of unsuccessful login attempts.
2.21 The solution should respond with a generic error message regardless of
whether the user ID or password was incorrect. It should also give no
indication to the status of an existing account. The generic message
should not reveal which of the authentication parameters is invalid.
2.22 The solution must expire a user account after the session has been idle
for a period of time. This should be parameterized to allow flexibility
in adjusting this value as required.
2.23 The solution should support re-authentication for sensitive features e.g.
before updating sensitive account information such as the user's
password, user's email, or before performing sensitive transactions.
The function(s) requiring re-authentication should be
configurable/determined.
2.24 The solution must not allow the re-use of a past password until a set
period of time and a set number of password changes have been made.
This should be parameterized to allow flexibility in adjusting this
value as required.
Session Management
2.25 The solution should allow only one session per user operating from a
single computer unless a specific business case has been established
for allowing multiple sessions per user. The allowing of multiple
sessions to users based on business needs should be configurable.
2.26 The solution should not allow concurrent user logins by a user from
multiple computers.
2.27 The system should allow the capture and storage of all relevant session
information in a secure and auditable location
2.28 The solution should implement secure session IDs, generation of
identifiers (IDs or tokens) must meet the following properties:
2.28.1 Session ID fingerprinting: The name used by the session ID should not
be extremely descriptive nor offer unnecessary details about the
purpose and meaning of the ID. The default session ID name of the
web development framework should be changed to a generic name.
2.28.2 Session ID length: The session ID must be long enough to prevent
brute force attacks, must be at least 128 bits (16 bytes).
2.28.3 Session ID entropy: The session ID must be unpredictable (random
enough) to prevent guessing attacks, a good PRNG (Pseudo Random
Number Generator) should be used.
Session Expiration:
2.29 Expiration timeouts must be set for every session regardless of the
activity. All sessions should implement an idle or inactivity timeout.
The duration should be parameterized and configurable.
2.30 The solution must provide a visible and easily accessible logout
(logoff, exit, or close session) button that is available on the web
application header or menu and reachable from every web application
resource and page, so that the user can manually close the session at
any time.
2.31 When a session expires, the solution must take active actions to
invalidate the session on both sides, client and server. The logs should
record the session expiration details.

21
2.32 When the user logs out of the application the session and
corresponding data on the server must be destroyed. This ensures that
the session can not be accidentally revived.
2.33 The solution should also force session logout on web browser "close
window" events.
2.34 The session ID exchange mechanism based on cookies must use
multiple security features in the form of cookie attributes such as
Secure flags, Http Only, Domain, Path, Expire and Max-age attributes.
2.35 In the solution design, backward process flows should clear all
authentication fields.
2.36 The solution should implement Role based Access Control (RBAC)
profiles for authorization based on business definitions.
2.37 Roles should be granted permissions based on the principle of least
privilege i.e. the solution should support an additive access model.
2.38 Access control must be granular to facilitate adequate separation of
duties including the following:
2.38.1 Functions should be independently available for allocation to a role.
2.38.2 There should be separation of duties e.g. data entry, authorization and
final approval.
2.38.3 Data entry staff should have the minimum access levels required to
enter data.
2.38.4 Authorization staff should have an access level that allows them to
authorize but not necessarily change the data that was entered.
2.38.5 Final approval staff should have the required access level to finalize
the process /transaction.
2.39 The solution should not access the database(s) as a privileged or
administrative user. The application should always connect as a non
privileged user.
2.40 If the database is accessed through a common application user, that
user should not own the objects in the database.
2.41 Credentials should never be stored directly within the application code
(hardcoding credentials).
2.42 Credentials should always be encrypted.
2.43 The solution should perform consistent authorization checking routines
when navigating on all application pages to ensure that the user
accesses what they are explicitly authorized to access by their roles.
2.44 For web based interfaces, the solution must use a secure method to
transmit data e.g. Using the HTTP POST method instead of the less
secure GET method
2.45 The solution should log all access authorization requests to a secure
and auditable location.
2.46 Error messages should be standard and not provide information
alluding to the reason for the error allowing an attacker to deduce
effective attack methods.
2.47 Logs should not contain password information.
2.48 Copy and paste must not work for data entry when authenticating to
the application.
2.49 All input fields must be validated to accept matching data types
including case sensitivity where necessary.
2.50 All data entry fields must have input validation mechanisms to prevent
cross-site scripting attacks.
2.51 Sensitive information must not be stored in a persistent cookie, or
other location on the client computer that does not have enforceable
access control mechanisms.

22
2.52 Any sensitive content sent to the client machine must not be cached,
unless encrypted using approved methods. The application should set
the proper directive to cause the client not to cache the sensitive data.
2.53 The solution should not present any sensitive information to
unauthenticated users.
2.54 All data exchanges between the solution and other systems should be
encrypted by an approved method.
2.55 The solution should only implement cryptographic functions selected
from an approved list. Any cryptographic functions used that are not
previously approved require an exception. Recommended algorithms
(with minimum bit lengths), in order of preference, are:
2.55.2 Hashing: SHA ‐512, SHA ‐256 or better.
2.55.3 Symmetric: AES256, AES192, AES128, 3 ‐DES (168 bits),
Blowfish(minimum 128 bits), Twofish (minimum 128 bits), IDEA
(128 bits),and RC4 (128 bits).
2.55.4 Public key: RSA(minimum 2048 bits) and DSA(minimum 2048 bits),
ElGamal (minimum 2048 bits)
2.55.5 Weak algorithms, such as MD5 or SHA1 should not be used.
2.56 Hashing should be salted and the values used for salting protected.
Only the hashed and salted value should be stored. (Passwords should
be encrypted)
2.57 All user activities and transactions such as printing, viewing, updates,
inserts and other data manipulation should capture and log showing
the date and time, user ID, session ID, the URL accessed and the
source IP & remote IP. They should indicate the parameters necessary
to uniquely identify the specific transactions done in the respective
transaction tables. This should be implemented independently from the
database audit trails.
Logging & Auditing
2.58 The solution should collect and log the following application event
logs:
2.58.1 Authentication successes and failures
2.58.2 Authorization failures
2.58.3 Session management failures
2.58.4 Solution errors, alerts and events
2.58.5 The solution start-ups and shut-downs, and logging initialization
(starting and stopping)
2.58.6 Use of higher-risk functionality e.g. addition or deletion of users,
changes to privileges, creation and deletion of system-level objects
e.t.c.
2.58.7 URL of the web page(s) accessed by a user for Internet facing
applications.
2.58.8 Modifications to the application
2.59 The solution shall collect and log the database events showing the
following information at a minimum:
2.59.1 Application User-id
2.59.2 Date & Time of event
2.59.3 The source and remote IP address
2.59.4 Type of event/action performed by the user
2.59.5 Module accessed by the user
2.59.6 Success or failure of the event
2.59.7 Source of the event
2.59.8 Before and after values (where applicable, i.e. master files)
23
2.59.9 Account creation, lockouts, modification, or deletion
2.59.1 Modifications of privileges and access controls
0
2.60 The solution should correlate application activity logs and database
transactions. That is for every database transaction, it should be
possible to explicitly identify the application activity responsible.
2.61 Every change to a database record should be identifiable to an
application user with a record of the time of activity and type of
operation on the record i.e. insert, update or delete.
2.62 A violation log must exist to track any attempted unauthorized access
to the application and should bear the following information:
2.62.1 URL accessed by the user
2.62.2 Particular activity intended/attempted by the user
2.62.3 Particulars sufficient to identify targeted transactions if available.
2.62.4 Workstation-id or IP address of access
2.62.5 Date & Time of event
2.63 All updates, inserts and deletes must be clearly traceable to an
application user with corresponding time and source information (IP,
module and function).
2.64 The solution should provide an interface to view and generate reports
of the logs.
2.65 All valid and failed login attempts must be logged with meaningful
information that is actionable for investigative purposes if fraud is
detected. However, passwords must not be logged.
2.66 All password recovery reset attempts must be logged with meaningful
information that is actionable for investigative purposes if fraud is
detected.
2.67 All user and account management changes and attempts such as
granting of roles and profiles, deactivation of users e.t.c. must be
logged and should include at minimum the following information: user
effecting the changes, date and time stamp, IP address used, user
affected
2.68 Database audit trails should be present for all dynamic and static tables
of interest, e.g. Parameter tables, Transaction Tables, etc.
2.69 All data entry and manipulations must be done through the application
interfaces and never directly to the database.
2.7 Where data is supplied to the application from an authoritative source,
the application must NOT allow users to modify this data.
2.71 Reference data should not be altered by users in subsequent
transactions.
2.72 Sensitive information should NOT be stored in hidden fields if the
application is web-based
2.73 If the application connects to a database, application server, or any
system that utilizes application IDs, it is using an account that has been
granted access to only objects and functions needed for operation of
the application. The application does NOT connect to a database as a
privileged user, such as the SA account in SQL Server or SYSTEM
account in Oracle etc.
2.74 If the system directly faces the Internet, it does NOT store or cache
confidential data. This includes file uploads and downloads, source
code, etc.
2.75 The solution should have mechanisms/controls to guard against URL
manipulation and/or targeted URL attacks.
2.76 The solution should have mechanisms to guard against user
impersonations.
24
2.77 The solution should allow identified functions to be accessible from
restricted networks.
2.78 The system shall generate a user id in the following format: The user
id generated for internal users must start with a character and accept
combination of numbers and text and conform to length set in
parameters table. If the first letter concatenated with numbers are less
than the length required then the system should pad the length with
zeros in between.

25
 SECTION VII - PRICE SCHEDULE FOR GOODS – 20% (To be revised)

Name of tenderer Tender Number Page of

1 2 3 4 5 6 7
Item Description Country of Origin Quantity Unit Price Taxes and Duties Unit price of other
(Kshs.) Payable (Kshs.) incidental services
payable (Kshs.)
1 Supply, Delivery, Installation,
implementation and Commissioning
of:

Customer Relationship Management

Solution

Note: In case of discrepancy between unit price and total, the unit price shall prevail.

Tender's Signature________________________ Official Stamp ___________________________Date__________________________

26
27
28
29