The ICT Processes

ICT Processes
Standard Operating Procedures

and
Good Practices
Prepared In
January 2002
By
OMSAR
Table of Contents
1.0 Preliminary and Administrative Activities ................................................ 1

Activity 1 : Define Business Objectives as Related to ICT ................................. 2
Activity 2 : Initiate and Plan the Good Practices Project ................................... 3
Activity 3 : Collect Documents Relevant to the Project ..................................... 5
Activity 4 : Conduct Risk Management for the Good Practices Project................. 6
Activity 5 : Establish Proper Communication Schemes ..................................... 8
Activity 6 : Setup a Performance Measurement Process ................................. 10
Activity 7 : How to Implement Standards .................................................... 12
Activity 8 : How to Manage ICT Projects ...................................................... 14
Activity 9 : Setup the Configuration Management Process .............................. 16
2.0 Managing ICT Human Resources ............................................................ 19
Activity 10 : Organize the Structure of the ICT Unit....................................... 20
Activity 11 : Identify the Required Competencies per Position......................... 22
Activity 12 : Identify Actual Competency Levels of all Staff ............................ 24
Activity 13 : Analyze Competencies to Identify Training Requirements ............. 26
Activity 14 : Identify Training Resources...................................................... 28
Activity 15 : Manage Training Material......................................................... 29
Activity 16 : Maintain Training Records........................................................ 30
Activity 17 : Define Recruitment Standards.................................................. 31
3.0 Relationships with Suppliers .................................................................. 32
Activity 18 : Prepare a List of Supplier Products and Services ......................... 33
Activity 19 : How to Audit or Qualify Suppliers ............................................. 35
Activity 20 : Prepare an Agreements Register............................................... 38
Activity 21 : Evaluation of Suppliers, Products, Projects or Alternatives ............ 40
Activity 22 : Recommended Issues to Consider in ICT Agreements .................. 42
3.1 Including Technical Specifications in Agreements ................................ 42
3.2 Schedule and Timing of Product Deliveries ......................................... 42
3.3 Costing and Other Financial Issues ................................................... 43
3.4 Software Upgrades and Updates ....................................................... 44
3.5 The Supply of Source Code .............................................................. 44
3.5.1 Suggested Solutions ............................................................. 45
3.5.2 Data Structure vs Source Code............................................... 45
3.6 Maintenance and Warranty Services.................................................. 46
3.6.1 Warranties and Maintenance on Equipment .............................. 46
3.6.2 Warranties and Maintenance on Software................................. 46
3.6.3 Terms Applying to Both Hardware and Software........................ 47
3.7 Support Agreements ....................................................................... 47
3.8 Ensuring Continuity of Services ........................................................ 48
3.9 Delivery and Acceptance Criteria ...................................................... 48
3.10 Authorization of Staff ...................................................................... 49
3.11 Copyrights and Intellectual Property ................................................. 49
4.0 Qualification Processes .......................................................................... 51
Activity 23 : Specification Qualification (SQ) ................................................ 53
Activity 24 : Installation Qualification (IQ) ................................................... 56
Activity 25 : Operational Qualification (OQ).................................................. 58
Activity 26 : Performance Qualification (PQ)................................................. 60
5.0 Logical System Access and Security ....................................................... 64
Activity 27 : Identify Functions to be Secured .............................................. 65
Activity 28 : Assign Privileges and Access Rights........................................... 67
Activity 29 : Assign, Distribute and Control Passwords................................... 68
Activity 30 : ISO Standards for Security ...................................................... 70
6.0 Physical System Protection, Access and Security ................................... 72
Activity 31 : Infrastructure – Server and Other Rooms .................................. 73
Activity 32 : Infrastructure – Cabling .......................................................... 75
Activity 33 : Infrastructure – Networks........................................................ 76
Activity 34 : Assign Physical Access Privileges .............................................. 78
Activity 35 : Assign, Distribute and Control Passwords................................... 80
Activity 36 : Insure the ICT Systems........................................................... 81
7.0 Information Integrity : Backup / Archiving and Data Protection............ 82
Activity 37 : Identify What is to be Backed Up and When ............................... 83
Activity 38 : Backing Up ............................................................................ 85
Activity 39 : Identify What is to be “Restore Tested” and When....................... 87
Activity 40 : Restore Testing ...................................................................... 89
Activity 41 : Good Back Up Practices ........................................................... 91
Activity 42 : Protection Against Viruses ....................................................... 93
8.0 Information Integrity : Business Continuity Planning ............................ 94
8.1 Business Continuity Plans ................................................................ 94
8.2 Classifying Disasters ....................................................................... 94
Activity 43 : Disaster Recovery Procedures .................................................. 96
Activity 44 : Disaster Recovery – Good Practices .......................................... 99
Activity 45 : Business Continuity – Contingency Plans ................................. 100
9.0 Software Application Development ...................................................... 101
Activity 46 : Using a Software Development Process ................................... 102
Activity 47 : Software Development Tools.................................................. 104
Activity 48 : Programming Standards ........................................................ 105
Activity 49 : Selecting Software Applications .............................................. 107
10.0 Operations Management ...................................................................... 109
Activity 50 : Logging Maintenance and Support .......................................... 110
Activity 51 : Control Dissemination of Hard Copies and Distribution ............... 113
Activity 52 : Good Practices for User Support ............................................. 115
Activity 53 : Managing the Supplies of the ICT Systems............................... 117
Activity 54 : Documenting Data Entry Procedures ....................................... 118
Activity 55 : Standard Data Entry Checks and Controls ................................ 120
Activity 56 : Using and Supporting Office Technology Products ..................... 121
11.0 Environment Management ................................................................... 123
Activity 57 : Define the Required Environmental Conditions.......................... 124
Activity 58 : Monitor Environmental Behavior ............................................. 126
1.0 Preliminary and Administrative Activities
The Guide commences with a set of Activities that are general. They do not fall under
any specific Information Process. Most are fundamental processes in that they apply to
the whole Department.
The ICT Processes Page 1

Activity 1 : Define Business Objectives as Related to ICT
Objectives : this Activity defines the steps needed to establish Policies and Goals for
using its current and projected ICT Systems. This Activity also assesses the degree to
which business/organizational plans and ICT plans are aligned. It determines the
appropriateness of the mechanisms for establishing the priorities of ICT investments
(New projects, changes to existing systems, etc). It establishes the governing rules and
structure of the ICT unit as a whole. Of critical importance is an assessment of ICT
spending.
Questions such as the following should be asked and answered :
• What is each ICT System for?

• What does the Department expect from each system?
• How do the systems impact the general strategy of the Department?
• Who are the beneficiaries of the Department’s ICT Systems?
• What are the Technologies selected for current and projected systems
• What is the justification for such selection? (Financial and otherwise)
• How does each system contribute to the Products and Services the Department is
to provide to the Citizen? Or to other Departments? Or to the outside world?
• What are the key performance indicators to be measured and tested to establish
the success of the system?
• What are the challenges facing the ICT Systems?
• What are the main risks facing the implementation of the Systems?
• What is the structure of the ICT unit setup to handle all the ICT processes?
Scope of usage : to cover all ICT Systems under current use or that are projected for
future use.
Risks : should such goals and policies not be defined, the Department risks acquiring
the wrong systems, using them in the wrong manner or even not estimating budgets
properly.
Documentation and Deliverables : prepare a document that responds to the above

questions and any others that the Department finds crucial. Such a document would
therefore establish the ICT strategy and plan for the Department.

Activity 2 : Initiate and Plan the Good Practices Project
Objectives : the Good Practices Project is an ongoing process. The Department will
benefit from an ongoing application of Good Practices. The Good Practices to be
implemented in the Department should form part of a long term Project that is well
planned, executed and monitored. The objectives of this Activity are to plan the Good
Practices Project according to modern project management techniques.
Scope of usage : restricted to the Good Practices Project. The Project will not be
involved in any other ICT projects except in so far as it may propose and implement
good practices for them.
Risks : should the Department not plan the Good Practices project properly, it risks the
following :
• Undefined or unclear scope of the Project (Too wide or too narrow)

• Undefined or unclear deliverables
• Undefined or unclear communications channels
• Undefined or unclear authorizations
• Improper scheduling of the the Project
• Poor definition of a Project Team : responsibilities, authorities, etc.
• Improper acquisition of resources required by the Project such as documentation,
project management, electronic documentation support, etc.
Critical Risk : one of the major risks involved is that of the Department not having a
Project Manager nor being able to assign a Project Team for the Project. This is a serious
situation and can be known in advance. It is suggested that the Department contact
OMSAR in such a case to study various other alternatives such as outsourcing, assistance
by other Departments, etc.
Standard Operating Procedure :
1) Define the Project Scope, Objectives and Goals.
2) Assign a capable Project Manager. Usually, this would be the Head of the ICT
Unit. However, in the case where the Unit has not been formed yet, the
Management may find other parties for this role.
3) Identify all stakeholders of the project. Stakeholders are all parties within and
outside the Department that may have a positive or negative interest in the
Project.
4) Ensure that the Project Objectives are understood by all stakeholders or persons
with active interest in the project. To do that, refer to the document developed in
Use the document arrived at in Activity 1)
5) Analyze the Guide of Good Practices to identify the ICT Processes of interest to
the Department and to determine the Activities that the Department needs to
implement.

6) Identify Alternatives and Options to such Activities. The Department may find
that there are other Activities it needs to implement as Good Practices which are
not mentioned in this Guide. This would be the right time to identify such
Activities and add them to the overall list required by the Department.
7) Define and establish the three main elements of any project. These consist of the
core elements of the Project Plan :
The functions and features of the Project (Deliverables)

The phasing, scheduling and sequencing of Activities
The estimates of the costs and resources needed to complete the Project
8) Highlight all exclusions : these are usually functions within the Project that some
stakeholder will “assume” are part of it but may not be. Identifying them at this
stage would save a lot of time and avoid disputes.
9) Identify all Project constraints. The assumptions are the “Implied” needs of
various Stakeholders. Convert implied needs to stated needs or drop them from
the Project.
10) State all assumptions. Assumptions often relate to various aspects of the Project
or the ICT Processes. Assumptions usually hide “implied” needs and cause gaps
between what was promised and what was delivered. This would reduce the
Quality of the Project.
11) Carry out Risk Analysis and Manage the Risks. (Refer to Activity 4)
12) Based on the above, define the Project Team, their responsibilities, authorities as
well as their lines of reporting. Typical roles in the team can be :
Management
Staff from the ICT Unit
Quality assurance or Internal auditors or inspectors
The units in which the systems are used
Refer to the note at the beginning of this Activity that points to the risk of not
being able to identify or assign such a team.
Some of the above activities will be expanded as specific Activities in the following
pages.
Documentation and Deliverables : the above definitions result in a Project Plan. This
has to be documented and circulated to all Stakeholders for final approval.
Good Practices and Recommendations : it is always critical to implement modern

Project Management practices. Ensure that the Project Manager has a good experience in
the above activities.
Acceptance Criteria : this Activity is considered accepted when a Project Plan is

approved.

Activity 3 : Collect Documents Relevant to the Project
Objectives : to collect all documents that will be of use during the various stages of the
Good Practices project. Such documents should be verified to be correct and up to date.
Scope of usage : documents related to the Department as a whole as well as to the ICT
Systems in use by the Department.
Risks : should such documents not be available nor be up to date, time would be lost
during the completion of the various activities to collect and bring them up to date.
1) Identify all existing documents that should be used such as :
Department charter
Ministerial decrees
Various lists and registers
Studies relevant to the ICT Systems
Mission statements
Vision statements
Goals and Objectives
Strategies for reaching such goals
2) Catalog such documents under a Register until they are subsumed under the
proper Activities. The Register would include the document names, type, status
and location.
3) Ensure that all documents are up to date.
Documentation and Deliverables : all the above documents along with the Register
that identifies them.

Activity 4 : Conduct Risk Management for the Good Practices Project
Objectives : in the early stages of the Good Practices project, the Department is bound
to face many unknowns. This Activity presents a procedure for analyzing and mitigating
the risks facing the Department. This would allow it to avoid problems during the later
stages. A detailed discussion of Risk Management is presented in the Appendix of
Supplementary Material of Supplementary Material. Risk Management should be
carried out by the Project Manager.
Scope of usage : the whole Project itself. Note that at this moment, the Department
should not be concerned with Risk Management for its own ICT Systems. Risk analysis
for the ICT Projects of the Department should be handled within those projects.
Risks :
• Not being aware of how Risk Management takes place.

• Spending too little or too much time analyzing Risks
• Closing down the Project or specific Activities if major risks are found rather than
attempting to resolve them
• Hiding risks from the eyes of the Management
• Improper assessment of probabilities and impacts.
Follow the details provided in the Appendix of Supplementary Material of

Supplementary Material. Here follows a summarized procedure of Risk Analysis and
Management :
1) Identify all events which may damage the Project
2) Assess the Risk or the likelihood or probability of each event taking place. This is
expressed as a percentage ranging from 0% (Not likely at all) to 100% (Certain
to take place).
3) Assess the Impact on the project should each event take place. Impacts are
assessed as a percentage that ranges from 0% (No significant impact at all) to
100% (Catastrophic impact).
4) For information’s sake, an impact should also be assessed in terms of the

financial or time loss it might cause. For example, there are two events have 70%
impact each. One results in a $200,000 loss while the other results in a 50 day
delay. This is useful because it gives the Department a better way of assessing
impact.
5) Find the Exposure : Multiply the Risk (From Step 2) by the Impact (From Step 3)
for each event. This is the exposure of the Department to this risk. This will be a
number that is between 0% and 100%.
6) List all Risks sorted by decreasing Exposure

7) Compute the Total Exposure of the Project by adding all Exposures.
8) Address the topmost exposed events and find ways to manage the risk. This can
be managed by reducing the probability and/or by reducing the impact.
Documentation and Deliverables : a risk analysis document for the project as per the
structure proposed in the Appendix of Supplementary Material of Supplementary
Material.
Good Practices and Recommendations :
1) Ongoing Review of Good Practices Project : review Risk Analysis during all
stages of the Project. The purpose would be to learn from earlier analysis as well
as to ensure that (a) none of the risks are still likely and (b) there are no new
risks.
2) Risk Analysis for the Rest of the ICT Systems : should be carried out on the
ICT Systems should any of the following situations arise :
• New projects are launched

• Before the commencement of every major phase
• Troublesome spots are found in a Project
• New management take over the Project
• New software or systems are introduced
• Changes in the organization take place
• Changes in technology take place
Risk Analysis cannot be underestimated. It is usually the only way to avoid future
problems.
Acceptance Criteria : upon submission of the Risk Analysis document along with the
proposed solutions to all risky events, this Activity would be considered complete.

Activity 5 : Establish Proper Communication Schemes
Objectives : Since the Project relies heavily on following “Quality” practices, it follows
that Communication between all concerned parties has to be properly defined for the
overall project. The objective of this Activity is to define the Communications schemes of
the Good Practices Project.
Scope of usage : the scope of the Project.
Risks : should the Department not have a proper Communications scheme for the
Project, the following risks may arise :
• Improper implementation of the Project Plan

• Lost information
• Activities that are not properly carried out nor completed
• Disputes between concerned parties
• Improper monitoring of the Project and hence loss of control
1) Issue the Project Charter : this is a document that formally recognizes the
existence of the Project and is the trigger for its launch :
• The Charter is generally in the form of a memo or a letter by the Management

• It clearly identifies the Project Champion or the main driving force behind the
Project and would probably be issued by that person.
• It lists other elements such as : the Project’s title, date of authorization,
Project Manager’s name, contacts and duties, a brief scope statement for the
Project, a summary of the planned approach for managing the project.
2) Prepare a list of all persons involved in the project : the Management Responsible
for the Project, the Project Team, the ICT personnel who will assist the Project
Team, key Users, other parties outside the Department.
3) Define the roles and responsibilities of each person on the Project
4) Define the communication level to be established within the Project :
What information to distribute?

Who to send it to?
When to issue letters, reports, minutes, analyses, etc.?
Who is to issue such documents?
Who gets copied?
Where is the communication stored?
What registers control the issue of such communications?
5) Identify the repository where such documents are to be kept and archived.
Documentation and Deliverables : the documents listed in the above SOP.

Good Practices and Recommendations : it is best that electronic copies be kept of all
such documents. Furthermore, key documents should be subsumed under the
Configuration Management activity.
Acceptance Criteria : the Activity is considered completed when all the documents
mentioned in the above SOP are collected and approved by the Management, the Project
Manager and all involved parties.

Activity 6 : Setup a Performance Measurement Process
Objectives : Performance Measurement is one of the key managerial techniques in the

modern world of organizations. What a Department can measure, it can manage.
This Activity presents how a Department can prepare various metrics needed for
performance measurement of ICT Systems.
Scope of usage : all aspects of work involving ICT. However, there is no reason why
the same methods cannot be used for other non-ICT processes in the Department.
Risks : not introducing a performance measurement scheme may lead to the following
risks :
• Measuring the wrong things

• Using the measures for the wrong reasons or taking the wrong decisions
• Taking measures irregularly resulting in fragmented series
• Not having the proper information about various processes
1) Identify the Areas of Concern the Department needs to measure. Based on the
currently popular Balanced Scorecard, these are usually grouped in 4 major
areas :
Financial areas
Citizen based areas
Internal Business Processes (Operations including ICT indices)
Learning and Growth (Includes Human Resources)
2) Prepare the Metrics for each of these areas. Examples :
• Citizen satisfaction as measured by an index usually prepared through a

survey and computed using the Weighted Index Scoring Procedure (Refer to
the Appendix of Supplementary Material of Supplementary Material).
• Number of vouchers entered in one day, week or month
• Number of documents returned per month because of error
• Number of complaint cases raised against the department per year
• Volume of transactions handled by the server per hour
3) Measurement Schemes : develop a document that defines how each of the

measurements can be taken and recorded. More importantly, define within the
document the Indicators that help the Department recognize whether particular
measurements are within or outside decision making areas.
For example, if the proportion of erroneous vouchers reaches more than 10% of
the total, the Department will need to look into what is causing such errors and
remedy the cause. The figure of “10%” is thus an indicator. The decision making
zone is any measurement above 10%.

4) Prepare databases, registers, tables or cards that can be used to register the
measurements.
5) Analyze the measurements on a regular basis for decision making.
6) When problem areas are identified through such measurements, develop remedial
actions to resolve them.
Documentation and Deliverables :
1) The Areas of Concern and the individual performance measurements showing the
indicators for each.
2) Measurements procedures which show how each measurement is to be taken.
3) Measurement results : statistics, tables or databases.
4) Recommendations and remedial actions that define the actions taken to remedy
problem or improvement areas.
1) It is very practical to use a spreadsheet to record all the measurements. It makes

it easier to analyze and chart them and analyze their trends.
2) It is highly recommended to use Statistical Process Control procedures (SPC) that

are in common use in Quality Control in the manufacturing sector.
2) Communicate the purpose behind the measurements. Very often, personnel are
suspicious of measurements as they might consider such activities as infringing
on their behavior.
3) Remain consistent with measurements. Changing the nature of the measure over
the years stops the Department from analyzing trends and growths.

Activity 7 : How to Implement Standards
Objectives : ICT goes regularly through phases of confusion followed by

standardization. Many aspects of ICT processes need to conform or comply with some
established standard. This Activity provides some Good Practices regarding the
compliance with Standards.
The benefits of complying with standards are the following :
1) To avoid breaches of any criminal or civil law, statutory, regulatory or contractual

obligations and of any security requirements
2) To ensure compliance of systems with organizational policies and standards
3) To ensure that various standards set by the Department’s Management,

international bodies, other Government agencies are implemented and that the
ICT Processes within the Department are compliant with them.
Scope of usage : all Information Processes. Standards may be external standards

issued by agencies outside the Department or Government such as the Control Agencies,
International Standards bodies, etc. They may also be internal standards setup by the
Department itself. For example, the Department may issue a standard for PC
configurations covering the following : clerical PCs, PCs for engineers and PCs for
management.
Risks : not complying with standards may result in
• Legal infringements
• Inefficient ICT processes
• Drop in quality
1) Identify the standards in question. These may be standards such as the

following :
Cabling standards : cable speeds, bending radius, maximum lengths, etc

ISO9000 standards
Year 2000 standards (Though we are after 31-Dec-1999, problems still exist)
Standards set by Software Development Processes such as documentation forms,
programming standards, coding techniques, database definitions, etc
Auditing standards set by the various Control Agencies in the Government
Arabic software standards
Purchasing standards set by Tendering Committees or Donors
Etc.
2) Train the ICT Unit staff so that they can identify the areas of applications and
implement and monitor the standards.
3) Implement the standards as part of properly managed projects.

4) Monitor and audit compliance as an ongoing activity
1) A list of all standards to be complied with

2) Documents that define the standards.
3) Implementation procedures
4) Tests that verify compliance
5) Results of the tests prepared on a regular basis
Good Practices
1) The ICT Unit should be constantly on the lookout for standards that may be
emerging. Often, getting familiar with a standard during its inception will result in
more efficient implementation.
2) Various standards such as the various ISO levels need to be purchased as they
are not available in the public domain. It is a good practice to budget for such
acquisitions and to constantly revert to the related web sites for information
about upgrades and their related costs.

Activity 8 : How to Manage ICT Projects
Objectives : Project Management is an organizational discipline that is becoming more

and more accepted as part of ICT life. A major area of inefficiency in ICT Units is the lack
of proper Project Management. This Activity emphasizes the role to be played by Project
Management in ICT Projects, specifically that of the Project Manager.
Scope of usage : covers all types of ICT Projects whether handled by the Department
or by its Suppliers.
Risks :
• Projects without management will eventually fail. Failed projects will not meet
their functional promises, their budgets nor their deadlines.
• Projects without managers will fail in the same manner.
• Managers without the right experience, profile and authority will not be able to
manage projects properly.
1) Responsibilities of the Project Manager : it is necessary that the Supplier

appoint a fully responsible Project Manager no matter what size or scope the
agreement has. It is also critical for the Department to appoint its own Project
Manager.
These two persons will work as counterparts jointly assuring the success of the
project.
The following is a list of responsibilities or functions a Project Manager has,

irrespective of whether the post is on the side of the Supplier or the Department :
• Reports to Senior Management

• The Manager is the Primary Driver of the Overall Project completing such
activities as : planning, execution, monitoring and control
• Coordinates between all parties
• Manages product scope and specification
• Manages resource allocation
• Manages project scheduling
• Tracks and monitors all Project activities
• Communicates project status and progress
• Facilitates team communications and interactions
• Communicates with project stakeholders
• Decides on key or critical trade off decisions
• Analyzes and manages risks
• Manages change control and configurations
• Implements Quality Assurance to ensures that the project maintains it Quality
2) Modern Project Management techniques : project Management principles

apply to all types of projects. Essentially, general Project Management is not very
different from ICT Project Management. The main differences lie in the

management of the scope of the products, ie, technical issues. ICT Projects
require the following additional principles and methods :
• The use of business modeling for systems analysis and design

• The use of standard Software Development Processes (Review Activity 46 :
Using a Software Development Process).
• The implementation of team structures is very specific to ICT processes,
especially those that handle software development.
• The content of the following general Project Management processes would be
different for ICT although the techniques are be the same : risk management,
quality control, costing, configuration management.
It is recommended that the Department look into the possibility of training their
own staff in ICT Project Management. One web site to visit is the Project
Management Institute’s website : www. pmi.org. It is a focal point of modern and
standardized project management practices.
3) Project Management Software : even if Project Management principles are not

learnt with proficiency, it is still highly recommended that the team use a
standard Project Management software such as Microsoft Project 2000™.
4) The Department should establish standards for Project Management to be applied

internally as well as requested from Suppliers. The latter can be part of the issued
Requests for Proposals. (Review Activity 7 : How to Implement Standards).
5) The Department should establish Performance Measurements and Indicators for

its own Projects. (Review Activity 6 : Setup a Performance).

Activity 9 : Setup the Configuration Management Process
Objectives : to setup a Configuration Management process, maintain it and benefit from

the results of the information it produces. Configuration Management controls all
components in an ICT System such as software, hardware, network components,
documentation, training material, media, password lists, etc. It also implements a
change control procedure to control and track all changes to the initial configuration.
In the Appendix of Supplementary Material of Supplementary Material, the Guide
defines the whole Configuration Management Process.
Scope of usage : the scope of the Configuration Management process totally depends
on what the Department wishes to include in the Configuration. At the most minimal
level, this would cover the ICT System hardware, network components and software
items. However, many other elements can be added.
Risks : not launching a Configuration Management process will lead to the following
damages :
• The Department will not know what is included in the ICT Systems which will
causes losses, open the system to pilferage, etc.
• The Department will have a difficult time updating, upgrading or gathering
information about the status of the system.
• Changes will take place in an ad hoc and uncontrolled manner leading to
discrepancies, losses, mismatches and other problems. This is especially
damaging in the case of software systems under development.
This procedure closely follows the detailed processed defined in the Appendix of
Supplementary Material of Supplementary Material. The steps discussed in the
Appendix are summarized below.
Standard Operating Procedure : Preliminary and One Time Tasks
1) Determine which Configuration Management software the Department wishes to

use to manage the Configuration. Once this is determined, it can be acquired or
developed and made ready for use.
2) Develop a Product Numbering Scheme and Hierarchy
3) Develop other coding schemes that may be used such as tag numbers, etc.
4) Identify and Determine the Configuration elements, items, components, etc.
5) Setup all items on the Configuration Database as they are on a specific date. This
becomes the Baseline Configuration. All subsequent additions, deletions and
modifications of items in the Configuration must adhere to the Change Control
System defined next.

6) Develop a Change Control Mechanism. This will allow the Department to control
all additions, deletions and modifications of any item on the Configuration.
Standard Operating Procedure : Ongoing Management of the Configuration
1) Use the Change Control System to ensure that any change to the Configuration is
subjected to the following process :
• Define the information needed to prepare a Change Request

• Request the change
• Analyze the Request : reason, impact, timing, costs, etc.
• Approve or reject the Request (Or request additional information)
• Implement the Change
• Record the Change in the Configuration Database
2) Changes such as the following are also subject to the same mechanism : addition
of new items to the ICT Systems, deletion of items or their removal or
uninstallation as well as any changes such transferred locations, upgrades, etc.
3) Monitor and Track the Configuration through the analysis of the information being
processed in the Configuration. (Review the Appendix of Supplementary
Material of Supplementary Material for a more detailed list of such information).
Good Practices
1) What to include in a Configuration?
The Configuration can include but not be restricted to the following items (In
alphabetic order) :
• Business Modeling Diagrams

• Cabling
• Compilers
• Databases
• Design specs
• DLL’s and ActiveX Components
• Documentation
• Hardware components and units (PCs, modems, scanners, printers, etc.)
• Integrated Development Environments
• Network components and units
• Object code components
• Operating Systems
• Power components and units
• Prototypes
• Queries
• RDBMS (Servers, clients, etc)
• Screen designs
• Servers
• Shell scripts
• Site units
• Environment units and test equipment

• Software Applications
• Software Tools
• Source Code
• Style sheets (CSS)
• Telecommunications components and units
• Test Data
• Test Plans
• Upgrades and Patches
• Web Pages
• XML Schemas
• Etc
2) Include Minor Databases and Registers : throughout most of the Activities of

this Guide, there is a constant recommendation to setup minor databases, lists or
registers as a means of documenting procedures. If the Department sets up a
Configuration Management process, it is advisable to setup these databases or
lists on the Configuration database. The following are examples of such items :
• Agreements
• Agreements with Suppliers
• Backup media
• Data sheets submitted by Suppliers for various equipment
• Items under maintenance agreements
• List of suppliers
• List of supplies
• Project plans
• System manuals and documentation
• Training institutions
• Training material
• Workshops and courses of such institutions
Over and above the actual software application to be used for Configuration
Management, the Appendix of Supplementary Material lists a variety of different
analytic reports to be reaped from such an application.

2.0 Managing ICT Human Resources
Human Resources are one of ICT’s major problems. The Technology is changing. Staff
are not progressively trained. Job Classifications are faulty and neither reflect the
Department’s needs nor the qualifications of the recruits. Responsibilities, generally
horizontal in the ICT environment, are not clearly understood nor efficiently
implemented.
All of the above lead to inefficiencies and risks such as :
• Poor performance in all areas of ICT

• Errors, rework, reruns, etc.
• High turnover of staff
• Demotivated staff
• Regressing technical knowledge and competence
• Problems within Project Management due to improper staff responsibility
allocations
The following sets of Activities provide some Procedures and Good Practices related to
ICT Human Resources.
These Activities are supported by an extensive section in the Appendix of

Supplementary Material regarding the Organization of a typical ICT Unit.

Activity 10 : Organize the Structure of the ICT Unit
Objectives : to define the Organizational Structure of the ICT Unit according to modern
principles. Different periods in ICT history have required different types of personnel with
different relationships. Different organizations operating in different environments have
also constantly had to change their structures. Hence, the Guide will not be able to
propose a standard Organization Chart for ICT Units. The Guide will propose a generic
Organizational structure that can be used as the basis for specific Units in each
Department. Such a structure is presented in the Appendix of Supplementary
Material of Supplementary Material to avoid disrupting the flow of Activities.
Scope of usage : the ICT Unit in the Department. However, some Departments might
have small isolated ICT units following major Directorates or Agencies that report to the
Ministry. These have to be considered as part of the overall structure even though they
may not report directly to the ICT Unit Director.
Risks : an ICT Unit without a properly understood structure is subject to disruptive

behavior :
• Overlap in responsibilities will cause tension and errors.

• Specific responsibilities or functions might be left unaccounted for leading to
improper performance.
• Personnel will team up in political or social groups causing damage to the overall
work.
• The structure cannot easily be modified as technology changes.
• Personnel will not be able to view their career path which is demotivating.
The Guide will use the term “Position” instead of a “Job”. The term position defines a
position that is created by the Department for a specific purpose. This position may or
may not be filled.
1) Identify all positions in the ICT Unit and the positions they report to.
2) Use a minor database to setup at least the following data elements for each
position :
Description
Date created
Grade / Subgrade
Date filled
Staff ID
Position it reports to
Responsibilities (Text)
The responsibilities of each person would be as they are doing the work today. It
would help to have the persons write down what they assume is their job. The
difference between what Management considers their job and what they consider
their job can often resolve a lot of issues.

3) Start by charting the ICT Unit on an “AS IS” basis.
4) Proceed by converting existing titles to industry standard nomenclature as

presented in the Appendix of Supplementary Material of Supplementary
Material. This would help clarify the responsibilities of each person. This is a
Position Classification exercise which is necessary for the other Activities
discussed below.
5) Continue by reshuffling responsibilities to fit the new structure for the

Department.
6) If a position is occupied, ie, not vacant, link that position to a simple Employee
record containing at least the following data elements :
Staff ID
Name
Title
Date of birth
Date of joining the department
Educational level (Linked to multiple records)
Work experience (Linked to multiple records)
By now, the Department should have a fully detailed Organization Chart showing which
staff is in which position.
The above Chart can be in a hard copy but it is recommended to have it in an automated
form. Such a form can be as simple as a spreadsheet, a minor database application or a
diagram.
Acceptance Criteria :
The Organization Chart needs to be approved by the Management of the Department

before it becomes official.

Activity 11 : Identify the Required Competencies per Position
Objectives : to identify which Competencies are required for each Position in the ICT
Unit. Competency is a special ability a staff member acquires through training, education
or experience. Within the ICT world, this could vary from technical to non-technical
competencies.
Competence is a major issue in ICT. The Technology changes so fast that staff who are
considered experienced this year may be without much experience in a year’s time.
Upon defining competencies, they can be used in the following areas :
• A position can be defined by its required Competencies

• The staff’s actual Competencies can be identified to assess their fit
• Training courses can be defined by the Competencies they enhance
• Competencies can be tested for in staff performance evaluations
Scope of usage : the whole Department but specifically, the ICT Unit.
Risks : not defining competencies will lead to the following risks :
• Improper evaluation of staff

• Inefficient training
• A poorly defined Organizational Structure
1) Identify Expected or Required Staff Competencies for each Position by listing all
experience, knowledge, education or training that each position should have.
2) Review lists of training courses for ICT personnel. This would identify
Competencies that may be required.
3) Group competencies under some classification in order to analyze them jointly.

The following example takes a generalized approach by grouping typical
Competencies under two groups :
Non-Technical
PC literacy
Managing Teams
Project Management
Configuration Management
Human Resources Development
Training
Business correspondence
Presentation skills
Reception work
English (Writing Level)
Arabic (Writing Level)
Etc

Technical
Developing in Visual Basic
Developing in Java
XML
NT Server Certification
RDBMS Design
Autocad
Lotus Notes
Microsoft Certified Professional (MCP)
Microsoft Certified Systems Administrator (MCSA)
Microsoft Certified Systems Engineer (MCSE)
Microsoft Certified Database Administrator (MCDBA)
Microsoft Office User Specialist (MOUS)
Etc
4) Within each Competency, it may be useful to define several attainment level. For
example, Office 2000 capabilities can be defined at beginner, intermediate and
advanced levels. The same may apply to Languages : Spoken, Read or Written
levels.
5) Review all new technologies being introduced in the Department to establish

whether additional Competencies are to be considered or not.
6) Avoid defining Competencies in a broad manner. This would disable the

Department from evaluating whether a specific person has reached the required
performance. It would also stand in the way of clearly identifying training
requirements. Try to have a highly focused definition of each competency.
A list showing all the Competencies required or expected of the Staff holding such each
position in the ICT Unit.

Activity 12 : Identify Actual Competency Levels of all Staff
Objectives : to analyze the education, experience, competence and project history of all
staff. From this analysis, the Department would get a list of the Actual Competencies
each person has. Later on, this can be used to compare the staff’s actual competencies
with the expected competencies as defined in the previous Activity. (Review Activity 11 :
Identify the Required Competencies per Position). In a later Activity, the Department can
analyze the gap between required and actual competencies therefore identifying training
needs. (Review Activity 13 : Analyze Competencies to Identify Training Requirements).
This would provide the Department with a solid basis for reaching the following :
• Evaluating the Performance of Staff

• Planning their Training
Risks :
• Not knowing the education, experience, competence and project history of the
ICT staff may lead to improper use of current personnel, poor career path
planning and inefficient training.
• If qualified staff are kept in the wrong positions, this would lead to demotivation
and reduced performance as well as increase the risk of turnover.
1) Prepare a list of all Positions in the ICT Unit.
2) For each staff member, analyze the following :
• Training attended within the Department

• Training attended before joining the Department
• Experience acquired within the Department
• Experience acquired before joining the Department
• Educational qualifications
3) Identify the Competencies each staff member has.
A list of all staff currently in the employ of the Department showing the Competencies of
each.
1) Personal interviews may highlight Competencies that were not identified from the
paperwork analysis. They may also help the Department drop some
Competencies which were wrongly attributed to the staff member.

2) Testing : in some cases, it may be useful to test staff to verify that they actually
do have a certain Competency and that it has not been forgotten due to lack of
experience or time.
3) It is often useful to have staff review their own Competencies and those of other
colleagues. This would further help the Management with the identification
process.

Activity 13 : Analyze Competencies to Identify Training Requirements
Objectives : to identify the training requirements of staff so that the training can be
budgeted for, approved, planned and completed. Having completed the two previous
Activities of Identifying the required competencies per position and Identifying all staff
competency levels, the next step would be to analyze the “Balance” or the “Gap”
between what Competencies are required and what each staff actually has.
Risks :
• Lack of proper training leads to reduced performance of the ICT Unit.

• If wrong training is offered, this may lead to the same damage
• Wrong training will also lead to wasted costs
• If staff are trained and not kept satisfied, they would leave the Department either
to another employ or would request to be transferred.
1) Complete the Activities discussed in the previous two Activities. These should
produce a list of all required Competencies per position and a list of all Staff along
with their actual Competencies.
2) Compare the two lists and identify the “Gap” or the Competencies needed by
each staff member to be fit for the position that he or she is occupying.
3) Gap Analysis may result in the following cases :
• The staff may be over-qualified for the position

• The staff may be under-qualified for the position but untrainable
• The staff fits the position he or she is in very well
• The staff may be under-qualified for the position but trainable
The first two situations have to be dealt with by the Department’s management.
The last situation is what is being sought in this Activity. It identifies the staff
member who is short of his or her position’s qualifications and would also define
the Competencies needed to make the person fit for that position.
4) The list of all staff and their required competencies can now be sorted by
Competency. This allows the Department to plan the training for all staff.
A list of all staff and their required Competencies. This can be resorted to show each
Competency with a list of the Staff that require it.
1) Such an exercise should be repeated at least once a year.

2) Such an exercise should strongly be tied in with Performance Evaluation
practices. It is usual to have yearly evaluations. During each Performance
Evaluation, the Department would test whether the particular Competencies had
been acquired or not.
3) It is important that a person whose Competency is to be acquired through his or

her own effort and not through training, should be informed that such a
Competency will be tested during the next Performance Evaluation. (Examples
such as language proficiency, communications skills, etc, can be acquired at the
personal level and not through training).

Activity 14 : Identify Training Resources
Objectives : to setup and maintain a register of available training. There are many
institutes offering training courses, workshops and programs in the field of ICT. With the
advent of the Internet, many sites also offer free or chargeable online training.
Risks : not having lists that are up to date will lead to loss of time when training is
required. Secondly, not knowing what is available in terms of training may lead to
misconceptions about what the staff may require in terms of their training.
1) List all institutes that offer training with data about them : location, contacts,
type of workshops, etc.
2) List key training areas offered by each institute
3) Relate each training area to specific Competencies identified earlier.
4) Correspond with institutes to keep the Department up to date.
5) Maintain a table of website links that offer free or chargeable online training.
1) The Department should have cost estimates for most of the training being
investigated.
2) Technical exhibitions and forums can be of major benefit. These do not represent
formal training. However, attending such exhibitions is always educational and
would provide the staff with exposure to new technologies and products as well
as present them with the chance to collect data sheets, attend lectures and
discussions.
3) Such information collected by various ICT Units in the government should be

consolidated. It can then be shared by setting it up on the web.

Activity 15 : Manage Training Material
Objectives : this Activity presents some Good Practices that aim at maintaining a list of
all training material : documents, CDs, tutorials, web sites, etc. Different persons will
attend different workshops or courses and bring back training material with them.
Invariably, such material gets spread around the Department and will not be shared
resulting in lost resources.
Scope of usage : all the Department including the ICT Unit.
1) Prepare a register of all such training material.
2) Such material can also be included in the Configuration Management database.

(Review Activity 9 : Setup the Configuration Management Process)
3) Share such registers or lists via the internal site of the Department or through
regular announcements or inter office memorandums.

Activity 16 : Maintain Training Records
Objectives : to setup and maintain a Training Control Database. Training control

systems have wide functions. However, it can be a simple matter to maintain a set of
Training records for the ICT Unit staff. The main purpose would be to plan training,
assign courses to staff and track the results of training per person and per institute or
instructor.
The application would cover the following functions by setting up the following records :
Staff members
Training institutes or training resources
Available workshops/courses
Required Competencies
Actual Staff Competencies
Planned training (Workshops, courses, etc)
Records of the actual results with evaluations of courses, instructors and
attendants
Costing analysis
Scope of usage : all the Department including the ICT Unit.
Suggested Approach
The Department can acquire such a system commercially. However, the design is not
very complex and can be easily developed into a minor database.

Activity 17 : Define Recruitment Standards
Objectives : to standardize recruitment practices and get the best out of recruitment of
staff. This Activity suggests a way to automate the Recruitment process. It also
recommends the maintenance of an applications register that allows the Department to
review its applicants and follow up on their recruitment.
Scope of usage : all personnel including ICT staff.
Risks : if such practices are not implemented, the Department risks the following :
• Accepting staff with the wrong or fraudulent credentials

• Insufficient knowledge about the recruit may result in accepting staff for the
wrong positions
1) Irrespective of the title being advertised, it is best to include in the clear job
definitions to avoid receiving more applications than needed.
2) On receiving applications, it is important to check work references. Some

applicants glorify the work they did at specific jobs.
3) Many applicants skip over jobs they had problems with. Gaps should be checked.
4) Educational qualifications should also be checked.
5) Multiple interviewing should take place either through panel interviewing or

through a series of interviews with different persons.
6) It is usually the case that ICT staff only get checked by ICT experts. This practice
is not efficient as an employee is not only recruited for his or her technical
knowledge. Experts in related areas such as the unit that will benefit from ICT
Services or the Financial Unit or Human Resources should also be part of the
interviewing process.
7) On recruiting a person, it should be easy to find a short term project that the
person can complete as a test of his or her capabilities. Projects in the order of
one or two weeks should normally be sufficient to verify the competencies of the
new recruit.
8) It should be a simple matter to setup a basic database of all CVs received. Very
often, the Department may already have applications that they need on such a
database thus avoiding time loss and additional advertising costs.
9) Review the Appendix of Supplementary Material for a presentation on the

setup of an applications register to help monitor, track and control the
applications received by the Department.

3.0 Relationships with Suppliers
Due to the wide variety of products and services needed by ICT Processes, suppliers
become a major part of the ICT Processes supplying the Department with such a variety
of products and services as the following :
• Hardware
• Networking components
• Telecommunications Services
• Web based services
• Software of all types : operating, tailored, off the shelf applications, office
technology, networking, development tools, database engines, etc
• Training
• Support and maintenance
• Recruitment
• Secondment of staff
• Etc
Some of the above products and services may be internally supplied, so that in a proper
ICT environment, it may be necessary to apply the same Good Practices to Suppliers as
to the internal sources.
The relationship with Suppliers needs to be Quality Controlled.
Proviso
This ICT Process in this Section as well as those in the next Section on the various
Qualifications are closely related to Procurement Policies that the Government and/or the
Department may already have in place. It is important to recognize the Activities in
these Sections as being recommendations and guidelines and that in no way will the
recommended Procedures and Good Practices replace official procurement policies but
should be supplementary to them.

Activity 18 : Prepare a List of Supplier Products and Services
Objectives : to setup a list of Suppliers with their offered products and services.
Suppliers are no more specialized as they were in the 80s and 90s. Suppliers that only
sold one type of product can now sell hardware, software, web services and consulting.
Setting up a list of Suppliers on a minor database will allow the Department to easily
locate suppliers by product or by service. Furthermore, this list can be used to maintain
a history of the relationship with the supplier evaluating their performance, prices and
general quality.
This Activity does not replace that of Supplier Qualification or Audit presented in the next
Activity. It compliments it by providing the Department with a wider list of products and
services to select Suppliers from. After such a selection, Supplier Qualification may take
place.
Scope of usage : the Department can expand this Activity to cover all products and
services that it is interested in. However, the Activity will address ICT services and
products.
Risks : should the Department not have such a list :
• It would take a longer time to arrive at the right choice of products and services
in the market.
• The lack of history tracking may cause the Department to purchase products and
services from suppliers that it had had a problem with in the past
1) Identify the major areas of Products and Services that the Department is
interested in.
2) Prepare a multilevel classification of such Products and Services. This can be used
to speed up search and cataloging.
3) Setup a minor database that contains a record for each Supplier. The database
can have the following functions :
• A record for each supplier

• A list of all products and services per supplier
• A list of the history of the Department’s transactions with the supplier
• The profile of the supplier : experience, typical projects, etc
• The team in the supplier’s company that may be of use to the Department
The database setup above that can produce lists of Suppliers or lists of products and
services.

1) As there would be many suppliers promoted on the web, it would be useful to

include such information on the Database.
2) It is important to coordinate with other Departments to avoid duplicated effort as

other Departments would have most likely gone through a similar exercise.
Furthermore, the experiences with different Suppliers may then be shared. This
would ensure that Suppliers improve their products and services.
3) Consult various directories to update the database. Currently, there are several
companies promoting business directories, some general and some directly
focused on ICT products and services.

Activity 19 : How to Audit or Qualify Suppliers
Objectives : with such a wide variety of suppliers in the market, the Quality of the
supply process becomes a critical issue to the Department. This Activity prepares the
Department with some Good Practices that result in Qualifying Suppliers. This is not to
be confused with some very strict and disciplined procedures for “Prequalifying”
Suppliers which may be project specific. This Activity presents a single process that
allows the Department to qualify whether it wishes to acquire products and services from
this Supplier in the future or not.
Scope of usage : mostly applied to Suppliers with whom the Department enters into a
Commercial Agreement. However, it may often arise that the Department can be the
beneficiary of products and services from International or Local Donors. It also often
happens that the Department may acquire products and services from other
Departments. All of these have to be taken into consideration when Qualifying Suppliers
(Or sources).
Risks : should the Department not have a Supplier Qualification procedure, the
Department may end up dealing with Suppliers that are of lower quality than it expects.
1) Supplier Lists : prepare lists of Suppliers classified by type of service or product.

It is a Good Practice to setup an efficient database that sets up other data about
Suppliers such as size, history, location, key personnel, etc. This was discussed in
the previous Activity 18 : Prepare a List of Supplier Products and Services.
2) Define the Type of Relationship Required : such relationships between the

Supplier and the Department may be ongoing or may be defined on a one time or
a project specific basis.
The Department needs to establish the different types or level of relationships it

requires from Suppliers. These are some of the usual levels of relationships :
• Long Lists of Suppliers that are suitable in general terms

• Short Lists of Suppliers that are more focused on specific projects
• Final Supplier Qualifications where selected Suppliers are subjected to very
strict procedures of Qualifications in a specific project.
• Prequalified Suppliers that have been subjected to formal procedures of
Qualification and are found suitable in general terms.
3) Each of the above relationships should have its own Qualification Procedures.
For example, here is a typical definition of a Short List relationship :
“For the Supply of Office Technology Products Training, the Department requires
a minimum of 3 and a maximum of 6 Suppliers to form a Short List. These
Suppliers should be evaluated with the following criteria so that any Supplier not
scoring above 70% would be dropped from the evaluation and the Department
will then select the Suppliers with the top 6 scores :

Relevant experience in general and for the specific project
Team profile
References
Age of company
Prior dealing with the Department
Compliance levels (ISO, DIN, BSI, etc)
Financial standing
Etc.
4) Evaluation Criteria are the heart of Supplier Qualification. Without clear

evaluation criteria, Supplier Qualification will not be Quality Controlled. The
Department needs to define very clear and easy to test Evaluation criteria that
allow the Department to accumulate scores for each of the factors it wishes to
use while Qualifying a Supplier.
Example : Long List Relationship : since this is a general list for use while
prospecting for Suppliers, rigorous testing may not be possible. Therefore, the
Department may find it simple and efficient to use 3 point scales for such
evaluations as the following :
Relevant experience (Yes, Maybe, No) 15%

Team Profile (Good, Medium, Bad) 15%
References (Good, Medium, Bad) 15%
Age of Company (Old, Medium, young) 10%
Prior dealing with the Department (Good, Medium, Bad) 10%
Compliance Level (ISO9000) (Yes, No) 30%
Etc. (Weights will then total 100%)
Example : Short List Relationship : a Short List will usually result in a set of
Suppliers invited to bid on a specific project. Therefore, short lists are more
demanding. They would require to have more rigorous testing such as sample
work, site visits, documented evidence, etc. Therefore, the Department would
find it necessary to expand the evaluation scale and use percentages.
In all above tests, the Department should use the Weighed Indexing Scoring
Method to arrive at its results. This procedure allows the analyst to normalize and
convert such criteria into one evaluation score. (Review the Appendix of
Supplementary Material where a detailed presentation is given of the Weighted
Index Scoring Procedure).
5) Qualifying Methods : depending on the nature of the project and the

relationship that the Department is going into with the Supplier, it may use one
or more of the following Qualifying Methods :
• Documented evidence
• Certified evidence
• Letters expressing interest in joining projects
• Proposals
• Company profiles / brochures
• Company presentations

• Product data sheets
• Product specifications
• Site visits
• Product demonstrations
• Response to questionnaires and specific surveys
• Interviews with key personnel
• Reference checking
• Qualifications checking
• Educational checking
• Compliance certification
• Evaluation of specific processes (Software development, installation
procedures, training schemes, etc)
6) Documenting Qualifications : having established the Evaluation Criteria in very

clear terms, all Supplier evaluations must be documented and approved by the
Evaluation Committee. Such documentation may be recalled in case of disputes
or contestation. Furthermore, future Supplier Qualification exercises may benefit
from the results of earlier findings.
Good Practices and Recommendations
1) Coordinate with other Departments who may have already carried out the
exercise of preparing such lists. In the future, the whole Government should be
able to share such information, especially if it is web based. This would also make
it easier for the Suppliers to keep their data elements up to date.
2) Quality Assurance Methods at the Supplier’s : department should investigate

any quality assurance programs used by the Supplier, their programming
standards, Software Development Processes (SDP), implementation
methodologies and their documentation reviews.
3) Compliance with International Standards : in some situations, the

Department would expect the Supplier to comply with specific International
Standards such as the various ISO standards. The Department should identify
such standards and request the Supplier to confirm compliance with them.
1) Supplier Lists
2) Evaluation Criteria
3) Qualification Results
Generally, it would be Good Practice to setup a database for each Supplier and then
setup a record for each time the Supplier was subjected to a specific Qualification
Exercise.

Activity 20 : Prepare an Agreements Register
Objectives : to prepare a list of all current agreements between the Department and
any outsourced services. The purpose would be to consolidate the location of such
agreements, monitor and track their performance as well as their other terms such as
renewal, expiry and payment schedules. Such a register would also allow the
Department to analyze possible cases of conflicts of interest.
Scope of usage : generally, this Activity is concerned with current Agreements.

However, there will be cases where agreements lapse for a short period or when
agreements expire but the information they contain is of historical or auditing value to
the Department. These two types should also be included in the list.
The following types are some of the agreements this Activity covers :
• Purchase agreements
• Maintenance and support
• Training
• Consulting services
• Secondment
Risks : should a list of agreements not be available, the following might take place :
• Agreements might lapse giving the Supplier the chance to change his terms with
the Department.
• Conflict of interest may arise. For example, a Consultant might be assisting the
Department in one project only to find out that the same Consultant is bidding for
a Software Development project with the Department.
• Payment schedules may be missed.
1) Identify all agreements with the Department
2) Setup a minor database that houses such data elements as :
• Agreement data : supplier, date, reference, expiry, etc

• Scope of agreement : deliverables, scope of work, schedules
• Renewal terms
• Physical location of agreement document (Or file number)
• Brief description of agreement
• Main items to be delivered
• Financial terms
3) Update the database on a regular basis as and when agreement elements

change.
4) On a regular basis, analyze the database to list all agreements that are about to
expire during the next month or two.

List of all agreements with minimal data elements.
1) Setup the agreements on the Configuration Management database
2) Link the agreements database with the Supplier database discussed in Activity 18
: Prepare a List of Supplier Products and Services.

Activity 21 : Evaluation of Suppliers, Products, Projects or Alternatives
Objectives : this Activity presents a summarized procedure on how to compute

Weighted Indices that combine various evaluation criteria into one number or index.
When evaluation criteria of proposals are not clear, Suppliers will unbalance their offers
to ensure that get selected. A more elaborate and detailed discussion of the Weighted
Index Scoring Procedure is available in the Appendix of Supplementary Material.
Scope of usage : whenever the Department wishes to evaluate Suppliers, Offers,

Products, alternatives the Weighted Index Scoring procedure can be used. It can also be
used for internal purposes such as Performance Evaluation of staff, projects, etc.
Risks : without proper evaluation, the following risks may arise :
• Suppliers may contest the selection process

• The selection process may result in unsuitable choices being made
• Suppliers may bias their proposals on false assumptions being made by them as
to what is “important” to the Department
1) Select the factors that best reflect the criteria that are important to the
Department and make them the Evaluation Criteria for the offer.
2) The following are examples of Evaluation Criteria that are mixed in that they
apply to different Information products and services :
Reliability
Technical fit with the Department’s requirements
Profile of the team
Profile of the company
Relevant experience
Knowledge of the business domain of the Department
Timing
Price
Offered features
Responsiveness to RFP (Have they understood what was requested)
Project Planning
Additional features
3) Assign weights to such criteria. Examples :
Typical Government Tender on best price
Price 100%
Equipment RFP on price and features
Fits with Requirements 30%

Price 70%

Consultancy Services
Price 30%
Company Profile 15%
Team’s Profile 20%
Responsiveness to RFP 10%
Relevant Experience 25%
Of course, any of the above criteria can be broken down further such as the
Experience in the last example :
Relevant Experience 25% can be broken down into :
Technical fit 10%

Business domain fit 10%
Project management 5%
4) Identify any pass/fail criteria. For example :
“Companies that do not get 70% on their technical score will not be considered in
the overall selection”.
5) Publish the evaluation scheme in full detail in the Request for Proposal so that
Suppliers can prepare their proposals according to the defined weights.
6) On receiving the proposals, each offer needs to be evaluated and scores given to
each criterion. The best score would be computed using the Weighted Index
Scoring Procedure defined in the Appendix of Supplementary Material.
Documentation or Deliverables :
1) The full evaluation scheme : the criteria, the range of scores, the weights and any
pass or fail conditions.
2) A list of all items to be evaluated with all their scores
3) The computation of the Weighted Index Score for each item
Acceptance Criteria : when the best item is selected according to the Weighted Index
Scoring procedure, the Activity is accepted.

Activity 22 : Recommended Issues to Consider in ICT Agreements
Objectives : many attempts have been made to develop Standard Agreements betwee
customers and suppliers. Due to the changing nature of technology, the different
circumstances surrounding each agreement and the various policies and strategies
followed in different Departments, it becomes very difficult to develop such Standards.
This is a fairly long Activity. It discusses a variety of problematic issues that may arise
while preparing Agreements and proposes solutions to such issues.
Scope of usage : the typical Agreements that will be considered are the following :
• Purchase Agreements
• Requests for Proposal
• Support Agreements
• Maintenance Agreements
• Warranties
Risks : poorly developed agreements may never be a risk until disputes take place. In
all cases, whether it wins or not, the Department would be the loser. It is the
Department’s objective not to have to fall back on Agreements and litigate. Therefore,
the major risks of these Activities are :
• Lack of agreements
• Poorly written agreements
• Agreements based on Supplier Proposals
• Agreements that over-pressure the Supplier leading to eventual poverty in
delivery and performance
• Agreements that do not address the issues discussed in the next few subsections
Specific Activities will have their own Risks and will be discussed in what follows.
3.1 Including Technical Specifications in Agreements
In Section 4.0, the Guide presents a set of Qualifications, starting with the Specifications
Qualification (Review Activity 23 : Specification Qualification (SQ) and Activity 1 : Define
Business Objectives as Related to ICT). These two Activities provided SOPs that ensure
that proper designs have been made and that Specifications to be used as the basis of
delivery are in place. The Guide will not expand on this issue in this Section.
3.2 Schedule and Timing of Product Deliveries
After the Technical Specifications, the second most important element in any project is
the Schedule and Timing of activities. Many Agreements present a broad listing of target
dates and delivery times. What is missing are some of the the following crucial dates :
• Detailed start and end dates of each activity in the project

• Identification of key milestones
• Identification of Delivery and Acceptance periods and expiries

• Identification of Warranty period starts and ends
• Identification of points when payments are to be issued
Also missing are the following elements related to timing :
• Sequencing of Project activities

• Contingency planning in case there are delays in the activities
• Manning or the effort required to complete the activites needed to evaluate the
reality of scheduling
• Assignment of Project personnel to individual activities
Here is a broad procedure for preparing the timing :
1) The Department usually starts by defining a broad and general timing. This would
be based on key milestones in the project.
2) The Supplier will then analyze the Products and Services being proposed.
3) Based on such analysis, the Supplier will then prepare a rigorous timing plan that
contains all activities, their duration and their sequencing.
In the Request for Proposal issued by the Department, it is highly recommended to

request the Supplier to submit a Project Plan, including all the above elements, in an
industry standard Project Planning Software product such as Microsoft Project 2000™.
3.3 Costing and Other Financial Issues
Usually, most agreements are overly concerned with financial issues. However, there are
various weaknesses to be avoided.
1) Internally, the Department should rigorously estimate the overall cost of the
products and services being requested. Poor estimates result in the following
risks :
• Proposals may result in wild variations leading to project cancelation. This

causes time loss and is unfair practice on the Suppliers.
• Suppliers may have prior knowledge of these poor estimates and may gear
their proposals according to them. This would result in poor deliverables being
proposed.
• Poor estimates may result in unrealistic scheduling of the Project.
• Estimates that result in larger than budget figures may cause the project to
be unnecessarily cancelled.
2) Payments should be related to specific deliverables that have a very clear

Delivery and Acceptance Procedures. (Review the discussions in Section
4.0 : Qualification Processes)
3) Gear payments to the actual work or deliverables by the Supplier. Suppliers often
suffer because the schedule of payments does not reflect the work or deliverables

being submitted by them. This puts a strain on their cash flow which will only
reflect itself on poorer performance and corner cutting.
4) Exchange Rates : clarify currencies in which payments are to be made and what
happens on the dates of payment should the rates differ.
5) Escalation Factors : costs must be projected over the coming years. If that is
not possible, an escalation factor must be specified that the supplier of such
services must adhere to so that coming costs are not increased by more than the
said factor.
6) Fixing Floats : The pricing of future products can be fixed by relating it to a

percent float above an international price list or any other basis that is mutually
agreed upon.
3.4 Software Upgrades and Updates
Software often goes through different releases and versions resulting in major upgrades
or minor updates.
1) Agreements should clearly specify whether the Supplier is responsible for

supplying such upgrades and updates and at what cost. Otherwise, the Supplier
would be under no obligation to provide the Department with such upgrades /
updates.
2) It is critical in an agreement to specify the duration during which the Supplier is

obliged to provide such upgrades and updates.
3) Upgrades or updates may require conversion of databases or some rework on the

data. It should be clearly spelt out in the Agreement as to who is responsible for
such conversions.
4) Upgrades or updates may also require the updating of source code in developed
applications. The Department should clearly cater for this situation : who is to
redevelop the software, at which cost and how long that would take.
3.5 The Supply of Source Code
Source code is always an issue in Software Contracts. There are two perspectives to this
problem :
The Supplier’s Argument : the supplier may have spent a lot of effort to setup
standard interfaces, components, reusable routines, clever solutions of problems.
Suppliers are usually reluctant to expose such practices. Secondly, with the Source Code
in their hands, Suppliers ensure continued maintenance and support agreements.
The Department’s Perspective : without Source Code, the Department is exposed to

the risk of the Supplier going out of business or being acquired by other companies. In
such cases, there is a risk of the software not being maintainable or supportable.

Secondly, Departments often feel that Suppliers hold them hostage because Suppliers
have the Source Code.
Both these views seem reasonable. However, there are clarifications and solutions to the
stalemate that often arises regarding source code custody :
1) It is cheaper for Suppliers to maintain and support software than it is for a

Department to learn and train its development staff to support the software. In
most cases, software companies do not have sufficient documentation within their
source code making it even more difficult to support by parties that were not part
of the development process from the start.
2) On acquiring the source code, most Suppliers would renounce their obligation to
support the application. The application responsibility becomes that of the
Department.
3.5.1 Suggested Solutions
It is recommended that the Department avoid problems related to support stoppage

through the following suggestions :
1) The Source Code should be made accessible in the case of bankruptcy or

acquisition of the Supplier by other interests not obliged to continue with its
support.
2) Agreements can state that the Source Code be placed in escrow with a Bank.
Under specific conditions, such as bankruptcy or stoppage of work, the Source
Code can be made available to the Department.
3) It is usual to state in such agreements that the Source Code is only to be used for
internal support of the Department’s application and that it cannot be used by
other parties nor divulged to them.
3.5.2 Data Structure vs Source Code
There is often confusion in the mind of ICT Units between Source Code and access to
data. In the case where the Department is only interested in accessing the data as it
pleases, problems can be avoided by the Supplier providing the Department with a clear
definition of the Database Structures. The ICT Unit can then use various Report
Generators or even develop software to access its own data analysis and report
production.
However, such a procedure also has its risks :
• Without proper documentation and training, users may not have a clear idea of
what the various data elements mean and how the data is structured within the
database. This might result in data inconsistencies and erroneous reporting.
• Inexperienced users may strain the system by devising queries that place major
loads on the system.

In all cases, data structure and its issues should be separated from the issue of Source
Code.
3.6 Maintenance and Warranty Services
In some cases, Maintenance is a continuation of the Warranty. In others, the services

offered in each are different.
3.6.1 Warranties and Maintenance on Equipment
1) The Department must have the Supplier clearly spell out what parts of the
equipment can be replaced free of charge. Generally, parts that are fixed and
subject to failure would be while consumables or items that are under heavy
usage such as print heads are not cover by warranties.
2) Duty cycles should be observed and defined. Invariably, one does find a small line
of print that limits the usage of a specific product to so many hours of non-stop
work. (For example, some printers are not to operate continuously for more than
a specified number of hours).
3.6.2 Warranties and Maintenance on Software
Generally, here are the services generally provided as part of the Warranties and
Maintenance of Software items :
1) Correction of errors : the term “Error” should be clearly defined. Generally,

errors are undisputable discrepancies such as :
Wrong totals or computations

Misalignments
Actions that promise a result and do not perform it (Buttons, menus, etc)
Crashes or application hangs
Misleading error messages
All spelling mistakes and typographic errors
Improper sequencing of work (Links that send you to the wrong place)
2) Supply of missing functions : should any function defined in the Technical

Specifications not be available in the delivered software, then this may be subject
to Maintenance terms. The Supplier would have to supply it.
3) Performance issues : generally, performance is difficult to specify. However,

there are accepted rules of thumb as well as clear technical specifications. The
issue of Performance is discussed in Activity 26 : Performance Qualification (PQ).
4) Upgrades and updates are often included as part of Warranty and Maintenance
services. (Review Section 3.4 for some restrictions on such upgrades and
updates).

3.6.3 Terms Applying to Both Hardware and Software
1) Specify clearly when the Supplier can be called. Usually, a business shift is
specified so that calls outside it are either not answered or are chargeable at
different rates.
2) Specify clearly how long a Supplier can take before responding to the first call.
3) Having taken the first call, specify clearly how long a Supplier can take before
resolving the problem.
4) Specify clearly what contingency plan the Supplier has if the problem cannot be
solved.
An example for hardware maintenance would help :
• Maintenance Hours : 8:00 till 14:00

• Calls made after 14:00 will be charged at an agreed upon rate.
• Calls should be responded to by a visit within 8 working hours from the time the
call was placed.
• Any problem should be resolved within 16 working hours (2 days) of the
response.
• Should the problem not be resolved within 16 hours from the response, then the
Supplier has to replace the component with a working one or change the unit at
no additional charge.
3.7 Support Agreements
Many agreements confuse support with maintenance and often combine the two. This
eventually leads to disputes.
Maintenance aims at retaining the system in the working state which it was supposed
to have been delivered in. It is the responsibility of the Supplier.
Support is any additional effort the Supplier has to put to support the Department.
Support includes such effort as :
• Additional training
• Resolving problems which are outside the control of the Supplier such as
breakdowns due to damages, power failures, force Majeure, etc.
• Assisting users in activities which are outside maintenance
• Developing minor reports, modifications and enhancements
• Secondment of personnel during critical periods such as end of month, end of
year, closings, etc
• Undertaking activities that are outside any agreed upon work such as upgrades,
migration, re-installing software, trouble shooting, etc.
Since Support is labor intensive, the following guidelines are suggested :

1) An estimate can be made of the time that needed from the Supplier in terms of
support hours per year.
2) Because such effort is to be booked in advanced, the Supplier will generally offer
them at a lower rate. The total is then booked at an agreed upon rate.
3) Should these hours not be used, the Supplier will still get compensated because
of the commitment he made.
4) Should the Department use more than the agreed upon hours, a rate for
additional hours will be agreed upon and used as part of the agreement.
Generally, it should be lower than the yearly rate.
5) Whenever support is needed, the Department will request it and document such
requests.
6) When possible, the Supplier will provide estimates of specific support work to be
carried out. The Department will need to approve such estimates before they can
be executed.
7) On a monthly basis, the Supplier will submit a statement of all hours used so far.
Only those officially requested and approved are included in the statement.
3.8 Ensuring Continuity of Services
Schemes should be established to ensure that the Suppliers guarantee continuity of

services in terms of supplying maintenance, support, spares, new products. Here are
some recommendations :
1) Duration of service : the agreement should include a commitment by the Supplier

to maintain his products up to a specified number of years. Penalties should be
included in case the Supplier defaults on this condition.
2) Spare Parts : with changing technology, products are often withdrawn from the
market after a few years and spare parts get into short supply. The Department
should estimate the life cycle of the products it is acquiring and ensure that spare
parts are made available by the Supplier during that period. Failure to do so
should result in compensation by the Supplier or change of equipment.
3) Software upgrades : as per the earlier paragraph on Software Upgrades and

Updates, the Agreement should also specify as to how long the Supplier is under
an obligation to provide such Upgrades.
3.9 Delivery and Acceptance Criteria
This is one of the most serious areas of disputes between Suppliers and their customers.
The main reason is the lack of an agreement on how such Deliveries are to be made and
what constitutes Acceptance Criteria.

Review Activity 24 : Installation Qualification (IQ) and Activity 25 : Operational
Qualification (OQ) for a detailed procedure for Delivery and Acceptance.
3.10 Authorization of Staff
Suppliers often deliver goods without there being a recognized party that has the final
authorization in certifying that the goods have been properly received. This will lead to
disputes because invariably, payment terms are tied to certified deliveries which in this
case would be postponed.
It is important to ascertain that persons expected to carry out key work in a project or
an agreement are authorized to do so. This is applicable on both the staff within the
Department and those carrying out the various activities in the agreement.
1) For each deliverable, state clearly which party is responsible for :
• Delivering it
• Installing it
• Ensuring that it is operational
• Certifying that it has been properly received as per agreement
2) In critical situations, it is important to have a written authorization for such

persons.
3) In the case where such persons are to be changed, documented notices should be
issued by the Project Manager.
(Review Activity 2 : Initiate and Plan the Good Practices Project where the Guide
discusses the importance of Project Management and the role of the Project Manager).
3.11 Copyrights and Intellectual Property
Various problems arise when Suppliers supply systems with software that is not legally
licenses for that system. This often happens with built in databases or software that is
inadvertently left on the installed systems.
Risks :
• Such installed software may be incompletely installed or may require modification

to the installed components. Therefore, at some time, the Department will need
the original media which are not available.
• It may not be possible to upgrade such software free of charge or at nominal
costs because it is not legally registered.
• No support on such software

1) Illegally installed software is theft. To ensure that the Department stays on the
right side of the law, make sure that a license document for each item of software
acquired is submitted with the software.
2) Always register the acquired software. This will make available to the Department
upgrades, patches, new announcements and support.
3) Note that “Shareware” is not equivalent to legally licensed software. The usage of
such software beyond specified time limits becomes illegal.
4) Investigate carefully the End User License Agreement (EULA) for the software.
Some software may only be licensed on specific number of machines or may be
restricted from usage in specific environment.
5) Some software requires upgrades in registration to maintain it in a valid form.

Using the software beyond the expiry of the current registration is not illegal but
will not avail the Department with the benefits of upgrades, support and
announcements.

4.0 Qualification Processes
A Qualification is a condition or standard that must be complied with. Qualifications are

critical because they are the basis of Agreements between the Department and its
Suppliers, even if these are internal Suppliers.
Qualification processes are usually required during any of the following processes :
• Development, installation and use of software applications

• Design of hardware configurations : networks, minicomputer systems, etc.
• Implementation of telecommunications networks
• Development of web based applications
• Preparation of computer sites along with all environmental equipment and
testers.
• Consultancy services : design, supervision, project management, etc
• Training
Whichever of the above processes is being implemented, externally or internally, the

Department needs to go through 4 types of Qualifications as in the following diagram.
1 SQ achieved during
Analysis and Specification
Design Qualification Design of Product
2 Development SDP or Qualifications performed by

or Technical Business Analysts / Designers
Construction Processes
3 IQ Performed by
Installation
Installation Quality Assurance Staff
Qualification
Operational PQ Performed by
Qualification Quality Assurance Staff
4 IQ Performed by
Performance
Use Quality Assurance Staff
Qualification
1) Analysis and Design : during that phase of the overall delivery process,
Specifications produced by the Designers must be qualified. The Specifications
Qualification has the objective of ensuring that the Technical Design will result
in a product or a service that complies with the Requirements of the Users.

2) Development or Construction : in software projects, the term “Development”
is used. Increasingly, the term “Construction” is being used to cover the phase in
all projects where the deliverables are being “built”. The Development phase will
requires ongoing qualifications. However, these are usually technical and follow
the technical processes being used. Such technical processes will not be discussed
in the Guide. For example, the Department may select to use Microsoft’s Solution
Framework Software Development Process. Within that process, there are various
checkpoints and milestones that qualify whether the designs are being properly
developed.
3) Installation : starts with delivery, goes through the installation of the products
and ends with the operation of the systems. Installation covers two major
Qualifications :
Installation Qualification aims at ensuring that the products have been

properly installed and are ready for operation.
Operational Qualification aims at ensuring that the products, once installed,

operate properly and are ready for use by the User (And for the next
qualification).
4) Use : once the systems or the products are ready for use, ie, they have passed
the Operational Qualification, Performance Qualification is carried out to
ensure that the products are performing within their expected performance
ranges. This normally includes response time, speed, capacity, throughput, etc.
The above four Qualifications are presented in the next few Activities.

Activity 23 : Specification Qualification (SQ)
Objectives : the purpose of Specification Qualification is to show that the controls

required to specify the design have been addressed and agreed upon by an authorized
party. The objective of this Activity is to provide an SOP for the Qualification of a wide
variety of Specifications (SQ).
Definition : the SQ is a technical, quality and commercial review of any product or

service that the Department is interested in acquiring externally or developing internally.
Once developed, the SQ becomes the basis of Delivery and Acceptance of the product or
service and hence the heart of any Commercial or Internal Agreement.
Example : a UPS has Specifications such as power capacity, battery capacity in ampere-
hours, number of output connectors, whether there is an RS-232 connection and related
software to use on the connected PC or not, whether there is an alarm when power is
down or unstable, etc. These are technical Specifications and can be verified by a
Specifications Qualification. Other issues to be raised in the Specification relate to how
the UPS operates :
• What happens when the power goes down?

• What happens when the power resumes?
• How do we charge the unit on first use or after stoppages?
• How do we turn off the alarms?
• How do we run the software on the PC so that it can shut down the operating
system with impending power drops?
Risks : the importance of the proper Specification of systems cannot be underestimated.

The lack of proper specifications is one of the major causes of failed ICT projects.
Projects would develop disputes, inappropriate deliveries and deliverables that do not
meet user needs. Such risks result from any of the following :
• Not having Technical Specifications

• Improper specifications or those that have not been properly qualified or
validated
• Specifications prepared by persons without the proper and related experience
• Specifications based on proposals or verbal definitions
Scope of usage : all system processes listed at the beginning of this Section :
• Development, installation and use of software applications

• Design of hardware configurations : networks, minicomputer systems, etc.
• Implementation of telecommunications networks
• Development of web based applications
• Preparation of computer sites along with all environmental equipment and
testers.
• Consultancy services : design, supervision, project management, etc
• Training
This Activity covers a variety of situations :

• when the Department is issuing an RFP that contains a design
• When the design team of the Department is preparing designs for its internal use
while developing or building systems
• When the supplier is proposing a system and must include a design with the
proposal
• When one of the products or services a supplier is delivering includes a systems
design.
The following procedure applies to all the above cases :
1) Identify the party that will approve the design specifications. The party should
be given the authority to approve such a design. This may be a single user or a
Technical Evaluation Committee.
2) Establish Standards : define ahead of time what standards are required to

ensure that a specific function or feature is properly specified.
Example : while developing software specifications, the Department may have a

set of standards for systems design.This is particularly critical for software
applications.
Example : while defining a network, the Department may have a standard for
drawing the network topography may be used.
This is a critical step as it is such standards that will be used when evaluating the
design in this SOP.
3) Collect Required Documents : identify and collect the documentation that the
Design would be based on. Such documents as the following may be needed :
• User requirements specification

• Functional specification (if available at this time)
• Supplier qualification or Audit Report
• Any related agreements
• Any purchasing standards
• Technical drawings
• Data sheets for equipment
• Catalogs
• Etc
In the case of including the design in an RFP, such documents must be included in
the RFP as an appendix.
4) Involve Users : ensure that the staff who will be the direct beneficiaries and
users of the deliverables are part of the planning process that defines what is to
be designed. The users must then analyze all documentation and approve it.
5) Review Specifications : the team setup to evaluate the specifications will now
review the specifications and establish whether or not they consist of a complete

system design that can be used for later construction, development, delivery,
installation and use.
6) Approve the Specifications : once the Specifications are seen as fit, they can
be approved and hence, released as the Technical Terms of Reference.
1) The design documents

2) All supporting documents
3) Standards for accepting Specifications
4) Specification Qualification Review report
1) In the case of complex designs, it may be useful to submit the design to experts
outside the Department. An independent objective review may pinpoint design
weaknesses that are hard to see by the team developing them. Such parties can
be other ICT Units in the Government or independent third parties such as
Consultants.
2) The presentation of the design in the RFP will be read by private sector parties. A
good practice is to ensure that the design, is very clearly presented. Some
designs that are included in RFPs are only clear to the parties that developed
them.
3) What to do with Demonstrations? many disputes arise from Departments

acquiring software only presented before agreement through live demonstrations.
Such demonstrations are risky because :
• Demonstrations are almost never complete

• Demonstrations may hide a lot of problems with the system
• Systems being demonstrated may not be the same as those being
delivered and it is difficult to compare the two.
To avoid this problem, consider demonstrations only as a means of clarifying

various functionalities. They would be used as a review of the “qualitative
aspects” of the systems. They should not replace Technical Specifications.
Once the party authorized to approve the design has issued its approval, the
Qualification of Specification is considered as accepted.

Activity 24 : Installation Qualification (IQ)
Objectives : before an ICT System is brought into use, it should be properly installed
and confirmed as being capable of operation. The objective of this Activity is to provide
an SOP for the Qualification of installation of a wide variety of systems. This is
essentially a delivery process and should not be confused with operational qualification
to be discussed in the next Activity.
Definition : Installation qualification (IQ) is the documented verification that all key
aspects of the installation adhere to approved intentions. These intentions could have
been expressed through :
• Design specifications
• System specifications
• Manufacturers' recommendations
• Developers’ recommendations
• Data sheets
Scope of usage : hardware, software or systems related to networks and

telecommunications.
Risks : the lack of proper installation qualification will result in the following risks :
• Disputes regarding what was and was not delivered

• Items or services are missed while delivery is taking place causing delays and
losses during later parts of the operation or the project
• Improper installation may result
• Discrepancies between what was ordered and what was delivered
1) Identify the party that will approve the installation. The party should be given
the authority to approve the IQ. This may be a single user or a Technical
Evaluation Committee.
2) Standard Installation Procedures : these are SOP’s that define Standard

Installation procedure for each type of system or deliverable being installed.
Installation procedures should be defined ahead of time by various parties
depending on the nature of the system being delivered.
The SOP will ensure that all components of the ICT System are installed as per
the specifications of the supplier or developer. The SOP should contain the
following :
• The step by step installation procedure

• The tests needed to verify that the installation has been carried out
successfully.
• The installation acceptance criteria without which the Department will not
be able to establish whether a system has been properly installed or not.

• Site or environmental conditions necessary for the proper installation of
the system.
• The party authorized to carry out the installation.
Should such a procedure not be available, then the ICT Department should
prepare one to ensure that the system is being installed according to a standard
process. The procedure may also include guidelines and related options.
3) Install the system as per the standard instructions and confirm each step.
4) Record all the test results.
5) Pass or fail the installed products.
1) Standards Installation Procedures for the type of system in question

2) The test results produced by the Installation Procedure
3) A document confirming the proper installation of the system in question.3)
4) A list of all documentation submitted with the system
5) A list of all components in the system to be used for Configuration Management
1) In all agreements, insist that Suppliers provide Installation procedures. Without

these, proper IQ cannot take place.
2) Document all installation problems for later use in Risk Analysis.
3) Update the Configuration Management database to reflect the installation.
4) Environment : make sure that physical location or site meets the installation
conditions specified in the system documentation for such factors as air
conditioning, low moisture, power, and room conditions.
5) Ensure that all related software is the proper version for the installation.
6) System Documentation : a list of all system documentation promised to be

delivered with the system should be compiled and tested against delivery of such
documents. The documents will be subjected to Configuration Control and must
be registered in the Configuration.
Acceptance Criteria : the system is fully installed when the installation process is
fulfilled as per the supplied Installation Procedure. It would then be ready for Operational
Qualification.

Activity 25 : Operational Qualification (OQ)
Objectives : Operational qualification (OQ) is the documented verification that each unit
or subsystem operates as intended throughout its anticipated operating range.
A system that has been properly installed is not often tested for proper use and
operation. Before bringing such systems into full operation, they should be properly
tested and confirmed as operating properly. The objective of this Activity is to provide an
SOP for the Qualification of Operation of a wide variety of systems.
OQ tests the built-in capabilities of the new system. In OQ there is a focus on specific
functions and how these functions can be tested. OQ consists of such assurances and
questions as the following :
• Do key functions of the system operate correctly as specified in the design?

• Does the system have the ability to operate all the software that either came with
it or was installed on it as part of the installation procedure?
• Can we demonstrate that the functions are working properly without errors and
missing functionalities?
• Can the system connect to all its units, be networked or be directly connected
and use the connectivity for the various functions involved?
There are two clarifications to be made :
1) Difference between installation and operation : there is often a confusion

between installation and operation. Many ICT systems can be installed and
confirmed to be ready to operate without being fully operational.
Example : a software developer may install a full software application and confirm
that it can be launched, some menu items can be accessed and it can be shut
down without error. However, this does not mean that it is fully operational.
2) Difference between Operation and Performance : OQ implies that all

functions and features promised with the system must be operational.
Performance implies that other factors such as loads, volumes and other capacity
and power related issues are not problematic. This is dealt with in the Activity 26
: Performance Qualification (PQ).
Scope of usage : hardware, software or systems related to networks and

telecommunications.
Risks : improper or lack of operation qualification may lead to the following :
• The Department may not be able to know whether the system can operate
properly or not.
• The system may be operated by the wrong persons
• Major deficiencies may exist in the system to be identified during later stages of
its operation (End of month, year, etc).

1) Identify the party that will approve the Operational Qualification. The party
should be given the authority to approve the OQ. This may be a single user or a
Technical Evaluation Committee.
2) Installation : ensure that the system has been installed properly through a
review of the Installation Qualifications results.
3) Operating Instructions : Ensure that the system has the proper operating
instructions. These could be SOP’s that define operation or use procedures for
each aspect of the system being tested. Operating Instructions should be defined
ahead of time by various parties depending on the nature of the system being
tested.
4) Test Procedures : ensure that the system has proper test procedures. It is
these tests that will decide whether the system is “Qualified” as operational or
not.
5) Operate each function of the system to ensure that they are in working order.
This can be carried out by the supplier of the system or by persons identified in
Step 1 above.
6) Record all the test results.
7) Pass or fail the products or services.
1) Standards Operating Procedures for the type of system in question

2) A document confirming the proper operation of the system in question.
3) A list of all test results
4) A list of possible causes and remedies in case the errors are diagnosed while
operating.
1) Include users in the test process
2) Cover all “testing zones”. For example, there are many systems that get passed
for regular operation leaving out of zone tests such as closing of periods or the
use of large values during data entry or the testing of record sharing and locking
in multi-user environments. Usually, the reason is due to lack of data, knowledge
or time.
Acceptance Criteria : the system is fully operational when the test process is
completed and no errors or missing functions are noted. Note that operation may be
completed and yet the system may not be performing properly. For this, the Department
may need to consult the Performance Qualification Activity.

Activity 26 : Performance Qualification (PQ)
Objectives : Performance is a measure of various parameters in a system such as

speed, response, capacity, power, etc. Performance Qualification (PQ) ensures that the
total system performs as intended in the specified operating range. The aim of this
Activity is to develop a Standard Operating Procedure that allows the Department to
verify that its systems are performing the way they should.
Scope of usage : the system includes all hardware and software components,
associated equipment, people and procedures that make up the system.
Which systems should be tested?
• New systems that are being delivered and used for the first time
• Existing systems to be qualified on a regular basis
• Systems that have undergone modifications
• Systems that have had additional usage
• Systems that have seen sudden deterioration of performance should be tested
and qualified
• Systems expanded to operate at a higher capacity
• Lack of knowledge as to what constitutes a performance measurement.

• Lack of knowledge of the indicators that define whether the measurements are
within or outside the proper ranges.
• Wrong measures are used.
• Measurements taken in wrong environments or using wrong data.
Risks : should Performance Qualification not take place, the Department may face the
following risks :
• Systems will slow down or break down during critical periods causing time losses
and interruption of operations
• It will be difficult to hold suppliers responsible for performance problems if these
are not tested properly.
• By the time that problems arise, Supplier agreements may be closed making it
difficult to hold them responsible for performance problems.
The following procedure is used to qualify if a system is running within its proper “
“Zone” of performance :
1) Defining the operating environment : a description of the use of the system

in the context of the work environment should be developed. For example, it
should be specified that this system is to be used by the employees in the
Department during their office hours from 8:00 till 14:00.
2) Setting operational limits : the SOP shall include testing the system against
(but not exceeding) its operational capacity.

The performance levels should be set by the user but should not exceed the rated
capacity provided by the supplier.
A set of measurement indicators should be developed and approved before

running the Performance Qualification (PQ) Scripts. Here are some examples of
indicators :
• When 20 users are using the system, the response time for accessing a
Citizen’s record should not be longer than 2 second.
• Opening a web page and viewing all images on the Intranet should take no
more than 1 second.
• Preparing a full statement of all certificates should not take longer than 15
minutes.
These indicators define the expected results of the test or the qualification.
3) Test Data : disputes will arise when different parties do not agree as to what
data is to be used. Agreements do not often specify that and Suppliers are
tempted to use test data rather than actual data. Users will often refuse to use
actual data stating that the data is not representative.
Therefore, the SOP should define what the Qualification Data is : actual data for a
full month? A full year? Random data generated specifically for the Qualification?
Abnormal data or data which is outside the operating ranges should also be
tested to ensure that it is handled correctly in the system.
Whatever data is to be used, the justification for using it should be documented.
4) Requirements for setting up the data : should it be required to setup special

data for the tests, then the procedure and requirements for such setup should be
documented in the SOP.
5) Test Procedures or scripts : the SOP must contain one or more Qualification
Scripts that describe the procedures needed to verify the performance of the
system against the User Requirements or the Indicators established earlier.
They should simulate the operation of the system in a live situation, using all
system components and operating procedures.
Here is an example of a typical database application test procedure or script. The

purpose is to test the response of the system using a Search program when 20
users are busy posting transaction vouchers :
1. Initialize the database to purge all transaction records

2. Generate test data as per part 3 of the SOP. (This is not included in this
example but can briefly be introduced as : create 200 citizen records, create
50,000 transaction records, etc).

3. Have 20 users log onto the system. They should be ready to use the
Transactions entry program when instructed to do so. For the moment, there
should be no entry.
4. Make ready a test station and log onto the system. Launch a the program
that searches for citizens using the location parameter. The program will
display all citizens that meet the entered location.
5. Do not search yet.
6. Prepare the users to start entry of vouchers without interruption. A supervisor
will time the start of entry so that users start one after the other with a 5
minutes interval.
7. As each user starts, the tester at the test station will search for the citizens
and note down the time it took the system to respond.
8. Once the last of the 20 users is left working for 10 minutes, the test is over.
9. Plot the response time as the users come on to the system and analyze the
results.
Since test procedures are often carried out by persons not located in the same
room, it is necessary to have a good way of communicating the procedure and
ensuring that all users know how to execute it.
6) Test Results : enter the test results in form reserved for such results in the SOP.
The executor should record, sign and date the results. Screen prints or electronic
logs should be retained to verify the results.
7) Unexpected Results : systems may crash or show unexpected behavior. This

should be documented for later analysis.
8) Should the SOP result in disqualifying the system, two steps are required :
• Diagnose the problem causing the lack of performance

• Initiate remedial action
The system should then be resubmitted for Performance Qualification.
9) Qualification Report : if the PQ generates extensive documentation, then a

summary report should be written. It should include such information as :
• Whether or not the qualification scripts were followed

• Whether or not the expected results were attained
• Description of any deviation from expected results
• Any follow-up activities to correct any deviations
1) The definition of the environment

2) The operating limits of the system
3) The Performance test scripts
4) The Qualification Report to include all test results, unexpected behavior and any
remedial action that is required for correct performance.

1) When systems are being designed or acquired from Suppliers, it would be the
right time to establish broad lines for Performance Qualification. At a later date,
more specific SOPs can refine the qualification criteria.
2) Where appropriate, automated testing tools may be used to record results. These
are available commercially.
3) Data may need to be charted or analyzed for averages, standard deviations,

trends, etc.
4) In some situations where performance suddenly deteriorates, there may not be

qualifications scripts. In this case, historical information may be used. However,
the actions taken, the data used and the results obtained when the historical data
was generated must be clear.
5) While carrying out Performance Qualification tests, the Change Control history for
that system must be analyzed to ensure that no changes have been introduced
which would affect test results. (Example : some systems have their memory
reduced to be installed on other systems. This would affect test results).
6) The PQ should always be performed at the user site and will include testing
specific to the user environment and defined ways of working.
Upon the successful completion of a Performance Qualification SOP for each system,
application, etc, that item is considered as passed. When remedial action is to be taken,
then the subsequent PQ will be subjected to the same conditions.

5.0 Logical System Access and Security
ICT Systems need to be secured so that specific functions can only be accessed by
specific staff. This is called the Logical System Access facility and is different from the
Physical access to the ICT Systems site. The latter is defined in Section 6.0 : Physical
System Protection, Access and Security.
Why should ICT Systems be Secured?
1) ICT Systems process information of a confidential nature. (Example : the health

sector may have storage of disease history for citizens which are confidential).
2) Some processes are the responsibilities of specific persons and must therefore not
be processed by others. For example, posting vouchers should be identified by
the person who posted them. This creates the necessary transparency.
3) Some procedures can only be executed by persons with the proper background
and training.
4) Some information procedures may put the Department under a liability and hence
should be secured.
Objectives
The objectives of the ICT Process of Logical System Access are :
1) To prevent unauthorized access, damage and interference to business premises

and information
2) To prevent loss, damage or compromise of information assets
3) To prevent interruption of business activities
4) To ensure that only specific personnel carry out specific functions
5) To prevent compromise or theft of information and information processing
facilities.
6) To detect unauthorized activities.
7) To protect the confidentiality, authenticity and integrity of information
The last Activity in this Section discusses the current Security Standard within the ISO
certification.

Activity 27 : Identify Functions to be Secured
Objectives : in order to control logical access to the ICT systems, the Department has
to prepare a complete list of all functions that are to be secured. For each item in the
functions list there would be a definition of the kind of accesses that may be allowed.
Scope of usage : typical functions are :
• Access to the network

• Access to a specific PC desktop
• Access to a particular database application
• Access to specific web sites
1) The Department’s management must decide who can prepare such a list.
2) List all types of ICT systems to be secured (See above list under scope as a
guideline)
3) Define the functions to be secured in each system.
4) Define the nature of access. These are called Privileges. These can be of various
types or levels :
• Record level : access to read, to write, to update, to delete records on

the database
• Data element level : this is more specific than record level security. If a
use can view a record, he or she will need to have special privilege to view
specific data elements within the record. For example : a user may view
the full purchase order but will need privileged access to view the
purchase price, or to view the salaries on employee records, etc.
• Function level : this is where the user can access major functions but will
need privileged access to activate minor functions within them. For
example, a user can create a purchase order but will need privileged
access to update the exchange rate, or change payment date, etc.
5) If the privilege is subject to an expiry period, then this has to be defined. This is
useful when employees are given time restricted privileges such as when the
supervisor is on leave and hands over his or her duties to someone else.
Documentation and Deliverables : the list of Accesses or Privileges.
1) Privileges in customized software : when software is being designed, it is a

good time to establish some of the above accesses and privileges. Many system
designers leave the security at the level of the database and hence, expose the
system to more than necessary.

2) Vendor security : database engines are often secured by a single password.
Knowing that password will allow intruders to access the database from outside
the application. Special care must be had to ensure that such a password is
protected either by making it dynamic or by changing it frequently.
3) Encryption : as hackers become more capable of penetrating systems, the

tendency is to encrypt the data using modern encryption methods. In the past,
this was not possible because encrypting the data had a detrimental effect on
system performance. Today’s systems are more powerful and can handle the load
of encryption.
There is not one way of encrypting data. The Guide can only recommend that the
Department look into the facility of encrypting data that is to be secured.
4) Remote Access to Site : some Departments provide remote sites access to their
system. These sites are to be secured so that no illegal access takes place. It is
important to ensure that all access from such sites is password controlled. As
discussed in the previous paragraph, Encryption may be used to further secure
the access. Should the access be through wide area networks, the
communications protocols should be secured. It is important to be able to log the
remote access and analyze it. Patterns in the usage of remote access may show
illegal attempts at access.
Acceptance Criteria : The list is considered accepted when the Management approve
its content.

Activity 28 : Assign Privileges and Access Rights
Objectives : having identified the functions to be secured on the ICT systems, the next
Activity is that of determining the staff who can access the various functions and assign
them these privileges.
Scope of usage : all staff who can access the system must be included. All the
privileges defined in the previous Activity must be included.
1) The Department’s management must decide who can assign such privileges to
the various members of staff.
2) Ensure that the previous Activity of identifying all Privileges and Access Rights
has been completed.
4) Prepare a list of all staff who might be able to access the system.
5) Group the staff by groups to ease the task of assigning privileges. For example,
all secretaries will have the same set of privileges. A new secretary will
automatically inherit the same privileges as the rest of the group.
4) The above two lists will form a matrix or a spreadsheet. At the top of each
column, enter the type of access. In each row, enter the name of the staff.
For example, under the column Exchange Rates and across from the Chief
Accountant row, you can enter ALL to signify that this person can create, read
or retrieve, update or delete a currency record. On the other hand, a specific
person, such as the Store Keeper, will have only R under his name because he
can only Retrieve the exchange rate but not delete it, update it or create a new
currency code.
Documentation and Deliverables : the list of all staff and their related Privileges and
Access Rights.
1) Review the list periodically as Staff may change posts and may retain privileges
they are not supposed to have. Secondly, they may then be restricted from
privileges they are supposed to use because of the change.
2) Review the list of Privileges regularly as new software is introduced or existing

software is modified or enhanced. Such software may have holes from which
unauthorized persons may access functions they are not authorized to access.
Acceptance Criteria : The list is considered accepted when the Management approve
its content.

Activity 29 : Assign, Distribute and Control Passwords
Objectives : once the list of all functions is prepared and all staff are given the proper
privileges of accessing the ICT systems, it is time to setup the procedure for assigning
passwords to staff. This Activity presents an SOP that ensures that the process itself is
safe.
Scope of usage : all staff on the list prepared in the Activity 28 : Assign Privileges and
Access Rights.
Risks : without such an SOP, Leakage of Superuser passwords or password lists will
cause the Department to be exposed to insecure systems.
1) Assign at least two Superusers in charge of all password assignments. They

should be either part of the senior management or entrusted to this task by the
Senior Management. This task must be authorized in writing.
2) A Superuser ID and password will be assigned to each Superuser by the

Management or sometimes, by the Supplier. (See Good Practices below).
3) Each Superuser can then create Logon IDs and Passwords for the staff, assigning
them the Privileges and Access Rights defined in the earlier Activity.
4) Users will be informed of their IDs and Passwords through some scheme such as
email or sealed envelopes.
The list of IDs and Passwords. This is a very secure document and must be stored where
it cannot be located except by the Management who issued it and the Superuser.
1) In some cases, the system may be able to display the list of all users and their
passwords. Such a privilege should only be given to the Superuser and the Senior
Management.
2) It is good practice to keep the password list outside the Department. This is a
procedure that allows the Department access to the list in case it is lost or access
to the system breaks down. Such lists can be left in escrow with a Bank or parties
that the Department can trust.
3) Users should be instructed to regularly change their passwords. This avoids theft
of passwords. Checks on this can be made at random.
5) Instruct Users on how to prepare their own passwords. Most users tend to use
such easy passwords as their phone numbers, dates of birth, names of children or
loved ones. These are targets for hacking. On the other hand, if passwords are

very complex, no one can remember them and users may write them down where
they are easily accessed. This is to be avoided. The Guide proposes that users
resort to complex words that have an easy to remember “sound” but have no
meaning. Passwords such as kledobim and friklasiv can be remember but cannot
be guessed.
6) In the case of tailored software, it is best to implement some security procedures

that avoid illegal access such as the following :
• Suspend the screen if a user enters a faulty password more than 3 times
in a row within a specific time, say 15 minutes.
• Prepare weekly or fortnightly system warnings for users to change their
passwords
• Stamp all records with the ID of the user who created the record and the
ID of the user who last modified it. This is a good audit trail.
7) One of the two owners of Superuser rights should regularly check his or her
access to ensure that he or she has not been deliberately or inadvertently shut
out.
8) Many systems are assigned passwords that can be cracked by the Suppliers or
are even set by Suppliers. These have to be checked to ensure that only persons
within the Department have such passwords.
9) It is a good practice to analyze transgressions so that the Department can tell

that specific areas are target to attack.
Acceptance Criteria : The list is considered accepted when the Management approves
its content, storage and means of frequent update.

Activity 30 : ISO Standards for Security
Objectives : ISO has established a standard for security (ISO17799) which is slowly
getting implemented in a variety of ICT systems. This Activity introduces this standard
and prepares for its implementation.
What is ISO17799?
ISO17799 is a comprehensive set of controls comprising best practices in information

security. It is an internationally recognized generic information security standard.
What is the use of ISO17799?
The standard is intended to serve as a single reference point for identifying a range of
controls needed for most situations where ICT systems are used in industry and
commerce facilitation of trading in a trusted environment
Background
The standard was first published as a Department of Trade and Industry Code of Practice
in the UK. In February 1995, it was repackaged and published by British Standards as
Version 1 of BS7799. At that time, it was not accepted widely because it was not flexible
enough. Furthermore, its acceptance was delayed because there were other issues such
as Y2K, etc. A major revision took place with the issue of Version 2 in May 1999 and
within the same year, formal certification and accreditation schemes were launched.
Supporting tools start to appear and it was soon published as an ISO standard.
What is happening now?
There is major activity taking place in terms of using the standard :
• Many organizations in the West are quoting intent to use the standard
• Some are well on route to certification
• Some organizations already certified through BS7799 are converting to ISO17799
General Description
The Standard, even as far back as the BS7799, was made up of 10 sections :
• Security Policy
• Security Organization
• Assets Classification and control
• Personnel security
• Physical and environmental security
• Computer and network security
• System access control
• Systems development and maintenance
• Business continuity planning
• Compliance

The above sections cover 10 Key Controls
• Information security policy document

• Allocation of information security responsibilities
• Information Security Education & Training
• Reporting of Security Incidents
• Virus Controls
• Business Continuity Planning Process
• Control of proprietary software copying
• Safeguarding of organizational records
• Data Protection
• Compliance with security policy
Good Practices
Embarking on a full certification is a complex task. However, if the Department is

strongly interested in Information Security, it should seriously consider the structure of
the Standard and start implementing the controls even without the aim of certification.

6.0 Physical System Protection, Access and Security
The following set of Activities are concerned with the following aspects of the Information
Resources :
• Physical Protection
• Physical Access
• Security
• Practical usage
The next few Activities shall adopt a different format due to the nature of the items
being reviewed. Each one will have a set of countermeasures (Which automatically point
to the risk to be avoided) and a set of recommended good practices.
Note : the Guide does not provide technical guidance. For example, the Guide will not
present the reader with the best ways to test cables or install servers. These are part of
the technical specifications and would be covered as per the guidelines of Activity 23 :
Specification Qualification (SQ).
Standard Operating Procedure : here is the procedure recommended for all items :
1) An inventory list is to be prepared of the existing Information Resources. If

implemented, it is best to use the Configuration Management database.
2) Using the items on the list, two major paragraphs are presented. One presents a
list of possible threats or risks. The other presents a list of recommended
countermeasures.
3) The Department can then form a baseline by surveying all the items and checking
whether the countermeasures exist or not.
4) Thereafter, the Department can select to remedy any shortcomings according to

its needs, budgets and practical considerations.
5) After the survey, the baseline is then updated. Indeed, the Department can
consider surveying the above material on an ongoing basis to ensure that the ICT
Resources are secure and protected.
1) A list of all items to be reviewed or surveyed. Normally, this would be based on

the items presented in this Section. However, the Department needs to setup its
own list.
2) A list of the physical protection, access and security levels (Or the
countermeasures that are expected for each item).
3) The survey results including suggestions for remedial actions.
4) Any remedial actions taken.

Activity 31 : Infrastructure – Server and Other Rooms
Objectives : should the ICT Unit be hosted in a dedicated building, the Building would
have its own Physical Protection and Access schemes. However, these are so similar to
measures and practices taken for other computer rooms that the Guide has grouped
them together. The objective of this Activity is to list the various items that fall under
Server Rooms and other Computer locations and identify the threats and related
countermeasures need to avoid them. Refer to the introduction of this Section for an
SOP that covers this Activity as well as for other Infrastructural items.
Scope of usage : there are various rooms that should have special considerations such
as :
• Server Rooms
• Mainframe or mini-computer centers
• Media Archives Storage centers
• Technical Infrastructure Rooms
• Computer Centers
• Protective cabinets (Which may house servers)
These rooms usually accommodate documentation, data media, additional equipment,

etc.
Risks : there are various risks involved in the handling of rooms or physical sites. These
are avoided by the following countermeasures :
Recommended Countermeasures
Adapted segmentation of power circuits
Hand-held fire extinguishers
Use of safety doors
Closed windows and doors
Intruder and fire/smoke detection devices
Avoidance of water pipes
Overvoltage protection
Emergency circuit-breakers
Proper earthing schemes
Air conditioning with positive outward airflow
Local uninterruptible power supply (UPS)
Remote indication of malfunctions
Redundancies in the technical infrastructure (Additional hubs, etc)
Development and use of Standard Technical and Organizational requirements for
server rooms
Door key management
Supervising or escorting outside staff and/or visitors
Entry regulations and controls
Inspection rounds
Ban on smoking
Monitoring of access to the room
Shielding or change of location to avoid interference : electromagnetic radiation,
cellular networks or generators.

Lightning protection devices
Availability of plans detailing the location of supply lines
Alert plan and fire drills
Good Practices
1) Any devices or equipment which require access by a large user group, e.g. a fax
machine or photocopier, must be located outside such rooms.
2) Combustible materials such as printer paper should not be stored in such rooms.
3) Avoid the use in computer centers of mobile phones or other units that have
transmission/reception facilities such as walkie-talkies and pagers. These can
cause considerable interference with the operation of the systems.
4) The rooms should not be occupied by regular staff. They should be used only
randomly and for short-term assignments.

Activity 32 : Infrastructure – Cabling
Objectives : cabling of ICT Systems covers all cables and passive components of
networks. Their scope is from any existing delivery point of an extraneous network
(telephone, ISDN) to the terminal points of network subscribers. The objective of this
Activity is to list the various items that fall under cabling and identify the threats and
related countermeasures need to avoid them. Refer to the introduction of this Section for
an SOP that covers this Activity as well as for other Infrastructural items.
Scope of usage : network components such as the following are considered as

equipment and are not dealt with in this Activity :
Repeaters, routers, gateways, couplers, bridges, etc.
Risks : there are various risks involved in cabling. These are avoided by the following
countermeasures :
Fire sealing of trays

Selection of cable types suited in terms of their physical/mechanical properties
Sufficient dimensioning of lines
Physical protection of lines and distributors
Prevention of transient currents on shielding
Neutral documentation in distributors
Monitoring of existing lines
Removal, or short-circuiting and grounding, of unneeded lines
Selection of an appropriate network topography
Selection of types suitable for required bandwidth
Documentation on cabling and related markings
Minimizing routing of cables to avoid damage
Provision of redundant lines
Avoid proximity to power or other interference sources
Good Practices
1) Make available all cabling plans and drawings in an easily recognized location. It
is often the case that other infrastructural technicians may need to work on the
structures and would hence be helped by tracing the cables.

Activity 33 : Infrastructure – Networks
Objectives : networking of ICT Systems covers all components of networks. The

objective of this Activity is to list the various items that fall under networking and
identify the threats and related countermeasures need to avoid them. Refer to the
introduction of this Section for an SOP that covers this Activity as well as for other
Infrastructural items.
Scope of usage : the following is applicable to different types of networks :
• Server-Based networks
• Networked Unix Systems
• Peer-to-Peer networks
• Windows NT networks
• Novell Netware based networks
• Heterogeneous networks
This Activity does not take network operating systems or the operating systems of client
PCs into account.
Risks : there are various risks involved in the handling of networks. These are avoided
by the following countermeasures :
Ban on using non-approved software

Survey of the software held
Escrow of passwords
Documentation on the system configuration
Designation of an administrator and his deputy
Documentation on authorized users and their privileges
Establishment of a restricted user environment
Documentation on changes made to existing ICT systems
Obtaining information on security weaknesses of the system
Division of administrator roles in PC networks
Training before actual use of a program
Training of maintenance and administration staff
Password protection for ICT systems
Use of memory resident virus detection programs that check for viruses coming
through the network
Periodic runs of a virus detection programs to scan full systems
Restrictions on access to accounts and/or terminals
Blocking and erasure of unneeded accounts and terminals
Network management
Regular data backup
Sporadic checks of the restorability of backups
Possible removal of hard disks or floppies from client stations
Good Practices

1) Use a suitable Network Management System. This is used to control all the
hardware and software components located in the local network. Such systems
should support the system administrators as much as possible in their daily work.
Network management includes all the precautions and activities for securing the
effective use of a network such as :
• Checking that the network components are functioning correctly

• Monitoring the network performance
• Centrally configuring of the network components
2) Use a suitable System Management application which is concerned with the

management of distributed ICT Systems. This includes :
• The central administration of the users

• The distribution of software
• The management of the applications
• Configuration management
• Performance management
• Error management
• Security management

Activity 34 : Assign Physical Access Privileges
Objectives : to determine the staff who can access the various areas in the Computer
Center and assign them these privileges.
Scope of usage : all staff who can access the system must be included.
Risks : not assigning Physical Access Privileges properly will cause the Department to be
exposed to insecure operations.
Types of Physical Access Control Schemes
A Department may introduce different types of physical access control schemes such as
the following :
1) Monitor entry manually through registration at the desk and the issuance of
visitor badges
2) Use automated badge card readers and provide staff with cards that can access
specific areas in the center.
3) Use password protected door locks
1) The Department’s management must decide who can assign such privileges to
the various members of staff.
2) Identify all systems that need to be physically secured and their locations.
3) Prepare a list of all staff who can access the system.
4) The above two lists will form a matrix or a worksheet. In each row of this
worksheet, enter the staff names. At the top of each column, enter the
system/locations of access. In each cell where a row and a column meet, you can
then indicate the type of access for that staff.
Types of access can be : visitor, worker, temporary, etc.
5) Depending on the type of Access System used, the Department can then issue
passwords, cards, etc.
Documentation and Deliverables : the list of all staff and their related Physical Access
Privileges.
1) Staff may change posts and may retain Physical Access privileges they are not
supposed to have. Secondly, they may then be restricted from areas they are
supposed to use. Review the list periodically.

2) In the case of access control through registry at the reception, it is important that
persons entering are properly checked through the use of their IDs, staff cards,
etc. When necessary, it can be dictated that such persons never enter the site on
their own but that they are escorted by an authorized staff member.
Acceptance Criteria : the list is considered accepted when the Management approve its
content.

Activity 35 : Assign, Distribute and Control Passwords
Objectives : in some cases, Physical Access to ICT locations may require passwords.
Such schemes as password protected door locks and cards require issuing policies. This
Activity aims at setting up the procedure for assigning passwords and/or distributing
access cards to staff.
Scope of usage : all staff on the list prepared in the Activity 34 : Assign Physical Access
Privileges.
Risks : this is a very risky activity. Leakage of passwords or password lists will cause
the Department to be exposed to insecure systems.
1) The Department’s management must assign at least two Access Administrators in

charge of all password assignments and card distribution. They should be either
part of senior management or entrusted to this task by the Senior Management.
This task must be authorized in writing.
2) The Access Administrator will then handle the creation of Passwords for all staff
and the production of the access cards.
3) Users will be informed of their Passwords through some scheme such as email or
sealed envelopes. Cards are also distributed through a secure scheme to ensure
that the right person has received the right card.
The list of and Passwords and/or the list of assigned Access Cards. This is a very secure
document and must be stored where it cannot be located except by the Management
who issued it and the Access Administrator.
1) It is good practice to keep the password list outside the Department. This is a
procedure that allows the Department access to the list in case it is lost or access
to the location where the list is kept is not possible. Such lists can be left in
escrow with a Bank or parties that the Department can trust.
2) The Access Administrator needs to regularly change passwords. This avoids theft
of passwords. Checks on this can be made at random.
Acceptance Criteria : the list is considered accepted when the Management approves
its content, storage and means of frequent update.

Activity 36 : Insure the ICT Systems
Objectives : to present a set of Good Practices that aim at insuring the various ICT
resources in the Department. The financial value of a Department’s systems along with
related equipment may reach a high enough value to warrant such an insurance.
Scope of usage : insurance can cover a variety of losses. These are defined in the Good
Practices section below.
1) Equipment : all equipment such as computers, communications components,

printers, scanners, etc, can be insured proportional to their financial value. These
can easily be insured against theft, sabotage, damages due to various reasons or
acts of civil strife.
2) Loss of documentation : training, operating and other documentation form a

major part of the ICT resources. Such documentation can be lost due to theft,
negligence, water, etc. These can easily be insured.
3) Loss of Work : loss of time spent on work caused by Force Majeure or other
damaging situations can be insured. Such work can be insured : recovery costs,
rework, reentry of data, reinstallation of software and systems, cost of the
emergency procedures, etc.
4) Loss of Source Code : this often happens in different ways. Source code may
become inaccessible for various reasons. Source code may be corrupted. Wrong
backup may take place. Backup media may be destroyed due to various reasons.
The Department can also insure itself against such losses.
5) Loss of Software Products : some of the more expensive products can be

insured. Loss may take place due to theft, corruption of media, loss or theft.
In many cases, losses can be averted by proper backup, increased Risk Analysis and
better physical security management as shown in the previous Activities in this Section.
In the case of setting up a Disaster Recovery System, various works can be insured.
Review paragraph (3) in the Activity 44 : Disaster Recovery – Good Practices.

7.0 Information Integrity : Backup / Archiving and Data
Protection
One of the most frequent causes of damage or the highest risks in ICT Systems is loss of
data or its corruption. The reasons are many : equipment breakdown, operator error,
software bugs, etc. The only effective measure that can be taken to ensure that
Information Integrity is maintained in an acceptable state is to have a rigorous Backup
and Archiving policy.
Some Definitions
Backup is the storage of data, source code, software products, scripts, etc., on a
separate medium that can be used to restore the data to its initial form if need be. This
could be a regular or an ad hoc activity.
Archiving : this term is essentially the same as Backup. However, some centers use it
to signify removal of the data or cyclical backup that is not very frequent. In all cases,
the procedures are the same as for Backup, so this Guide will not differentiate between
the Backup and Archiving.
Purging : removing data from the initial medium to make space or reduce database
size. Example : transactions are kept within the operational database for the current and
the most recent 3 years. On completion of each year, the ICT Unit would need to purge
the oldest year from the database.
Checkpoints : these are points in time where the Department has to take a full backup
so that disaster recovery schemes can be used to restart the system from such
Checkpoints. (Review Activity 43 : Disaster Recovery Procedures)
The following Activities present various procedures and good practices related to the
above.

Activity 37 : Identify What is to be Backed Up and When
Objectives : the purpose of this Activity is to document the data and software that
needs to be backed up and/or purged. A Back Definition List will define the scope of
the data and will include a variety of information about each specific backup.
Scope of usage : the following is a recommended list of data and software but is not
restricted to these items. These are targets for back up :
Operational data (Used by the various software applications)

Development data
Source Code
Scripts
Web pages
Graphics used in screens
Documentation and help files
Test scripts
Test plans
Operating data
Shell scripts
Operating Instructions
Software products
Libraries
Compiled systems (To avoid recompilation on restore)
Off the Shelf Commercial Software
Updates / Upgrades / Patches
Operating Systems / Tools / Utilities
User Data
Data that is processed on client stations and centrally stored on servers
Reports
ASCII based output
COLD technology output : Computer Output on Laser Disks
Acrobat Reader output (PDF files)
Risks : not preparing a proper list of items to be backed up will cause the Department to
be exposed to loss of data.
1) Classify the types of data to be backed up as suitable for the Department. Refer
to the Scope of Backup above for a proposed classification.
2) List all data in appropriate groups. For example, it is inappropriate to backup

master files on their own. These should be backed up with all related transaction
and parameter files.
3) Prepare the Backup Definition List which contains the following data
elements :
• The frequency of backup : daily, weekly, monthly, end of cycle, etc.

• When to backup? : in case backups are required on an ad hoc basis.
• The type of backup : is this an incremental backup or does it fully replace the
data? Is it a purge or a copy? Etc.
• The type of backup media and where it will be located.
• Who is to carry out the backup?
Good Practices :
1) User Input : it is good practice to include users when defining the Backup
Definition List. Users usually have a good sense of how to avoid data loss and
would indicate at which critical points backup is to be made.
2) The Backup Definition List may be setup on the Configuration Management

database if that is suitable. Changes to the list can then be controlled.
3) When to backup? Most centers tend to backup at specific frequencies such as

end of day, end of week. However, there are other times when backup becomes
necessary :
At the end of specific business cycles

Before migration to new systems (Equipment or software)
Before upgrading/updating software or introducing patches
Before relocating systems
Before introducing new staff/users to the system
In fact, any time the Department feels that there will be a risk of data corruption,
backup should take place.
4) Regularly review the Backup Definition List as it often arises that new systems or
situations arise such as those in the previous paragraph that will require the
Department to update the list.
Acceptance Criteria : the Backup Definition List is considered accepted when the
Management approves its content, storage and means of frequent update.

Activity 38 : Backing Up
Objectives : to prepare a Backup procedure observing all backup requirements stated in

the Backup Definition List and to ensure that there is a record of all backups taken for all
types of information. This is the most crucial Activity to be carried out by the
Department and it aims at maintaining Information in total integrity. It may be time
consuming and it may be costly, but it is an insurance against data loss or corruption.
Risks : not backing up the data on a regular basis will cause the Department to be
exposed to loss of data and software items.
1) Consult the Backup Definition List on a regular basis to ensure that no backup is
missed.
2) Backup Media : ensure that there is available media for the backup well in
advance of the backup itself. Many centers lose valuable data because media is
not available and operators end up backing up over backed up media with useful
data.
3) Complete the backup and fill in a register that has the following recommended
columns :
Date of backup
Time of backup
Type of backup (Incremental, full, purge, etc)
Source data : describe it and its status
ID of the backup as per the Backup Definition List
(Refer to Activity 37 : Identify What is to be Backed Up and When)
Operator
Media type
Media label
Where the media is to be stored
Has restored testing been tried?
Result of restore testing
Remarks
The backup register which can be a printed form or a database.
1) Centralization of the Backup Register : in the case where Departments have

several sites, servers, applications, etc, it would be necessary to have a
centralized register. Copies of printed forms can be sent to such a location. If the
register is setup on a minor database, then it can either be located centrally and
made accessible to all operators, or different databases can be consolidated on a
regular basis.

2) Configuration Management : it may be suitable to setup the Backup Register
as part of the Configuration Management database.
3) Securing Backup : some centers follow the recommended practice of carrying

out the backup by well trained personnel. In order to do that, some security
measures may be implemented so that only such persons can carry out the
backup.
4) Review the Activity 41 : Good Back Up Practices
1) On a regular basis, the Backup Register should be checked against the actual
media. Verification can be made that the backup entries correspond totally to the
stored media.
2) On a regular basis, the Backup Register should be checked against the Backup
Definition List prepared in the earlier Activity 37 : Identify What is to be Backed
Up and When. Verification can be made that all items in the Backup Definition List
are being properly backed up. (To facilitate matters, the Backup Definition List ID
is included in the Backup Register).
2) More importantly, and this will be discussed in the next Activity, restore checking
should be made on random or specific backups. This should be part of the
Acceptance Criteria of the Backup Register preparation.

Activity 39 : Identify What is to be “Restore Tested” and When
Objectives : many centers face major upsets upon realizing that their backed up media
is badly backed up or is corrupted. The main reason for such a state is the lack of testing
of the backed up media. Sometimes, it is a matter of deterioration of the backed up
media or its environmental corruption. This Activity presents a procedure that defines
what media is to be “Restore Tested”, how frequently and what the tests are.
Scope of usage : all data that is backed up may be subjected to Restore Testing.
Risks : not testing backed up data will cause the Department to be exposed to loss of
data and software items.
Standard Operating Procedure
1) Identify the type of data to be Restore Tested and enter the relevant information
on the Backup Definition List prepared in Activity 37 : Identify What is to be
Backed Up and When. The ID of that item would then be known. A new List can
then be prepared which can be called the Restore Definition List.
2) For each item in the Restore Definition List :
• Define the frequency of restore testing : daily, weekly, monthly, end of

financial period, etc.
• Define the mode of testing : is this a simple hardware test? Is it a logical data
checking test? Etc.
3) For each item in the Restore Definition List, prepare a Test Plan that covers all
aspects of the Restore and its testing. A typical test plan is presented below :
• Prepare sufficient space on the local disk

• Ensure that the versions of the operating system that is running, the version
of the application software and the database structure are all compatible.
• Physically restore the data into the hard disk
• Logically restore the data into the database server (Import, etc.).
• Run the program that presents a list of system parameters : number of items,
number of citizens, number of transactions, etc.
• Compare the above list with the same list produced on the day when backup
was made.
• Pass or fail the test
Documentation and Deliverables : the Restore Definition List.
Good Practices :
1) User Input : it is good practice to include the users when defining the Restore
Definition List. Users usually have a good sense of what is risky in their work.
They would help the ICT Unit identify which data is to be tested, when and what
constitutes a good Test Plan.

2) The Restore Definition List may be setup on the Configuration Management
database if that is suitable. Changes to the list can then be controlled.
Acceptance Criteria : the Restore Definition List is considered accepted when the
Management approves its content, storage and means of frequent update.

Activity 40 : Restore Testing
Objectives : this Activity presents a procedure that allows the Department to reduce
the risk of bad backup media through regular Restore Testing.
Scope of usage : in most cases, it is too costly and time consuming to test all backed
up media. However, frequent and random tests can reduce the risk of damaging
situations.
Risks : not carrying out restore testing will cause the Department to be exposed to loss
of data.
1) Consult the Restore Definition List to identify the items that require Restore
Testing.
2) Prepare the receiving system for the Restore and restore the data
3) Apply the Restore Test Plan as indicated in the Restore Definition List.
4) Prepare a Register that shows the Restore Test details and results :
Identify the ID of the backed up media to get all the data elements for it
Date of Restore test
Time of Restore test
Type of backup (Incremental, full, purge, etc)
Operator
Test script or plan
Result of restore testing
Pass or Fail
If fail, remedial actions
Remarks
5) Pass or fail the test as per the Test Plan.
6) If the Restore Test fails, the Department would have unusable data. It becomes
the responsibility of operators to do one of two things :
Data recovery is possible : the operators will recover the data through some
means like reindexing, etc. Alternatively, they can get the data from duplicate
media stored outside the Department.
Data recovery is not possible : if neither of the above schemes is possible, the
operators would need to give warning to the ICT Unit Management and the user,
that such data is not available. In case of needing such data, it may have to be
re-entered and processed.
7) In all cases, enter the data related to the Restore Test in a Restore Test Register.

Documentation and Deliverables : the Restore Test Register.
1) It is important to relate Restore Testing with the Business Continuity Process

discussed in the next Section.
2) Configuration Management : it may be suitable to setup the Restore Register

as part of the Configuration Management database.
3) Securing Restore Testing : some centers follow the recommended practice of

carrying out the Restore Testing by well trained personnel. In order to do that,
some security measures may be implemented so that only such persons can carry
out such Tests.
4) Auditing Restore Testing : similarly, some centers may wish to have auditors
or user representatives on the spot when such tests are carried out.
On a regular basis, the Restore Register should be checked against the Restore
Definition List prepared in the earlier Activity 39 : Identify What is to be “Restore Tested”
and When. Verification can be made that all items in the Restore Definition List have
been properly tested.

Activity 41 : Good Back Up Practices
Objectives : the main aim of this Activity is to present a set of Good Practices that
apply to the variety of back up procedures presented so far.
Scope of usage : covers all types of data backup.
1) Media Availability : ensure that there is available media for the backup well in
advance of the backup itself. Many centers lose valuable data because media is
not available and operators end up backing up over valid and much needed
backed up media.
2) Labeling Procedures : one of the major problems facing ICT Units is that when
a backup medium is required for restore, the operators are never sure which data
it contains. Labeling is important but not sufficient. A rigorous scheme for labeling
must be followed and should be linked to the Backup Definition List identification.
This should also include Directory or File Listing so that file dates are clearly
shown.
3) What to do with Local Data? With the increasing spread of PCs on user desks,
larger and larger portions of a Department’s information will be processed on
these local PCs. This presents a risk to the Department because users are not
very disciplined about their own backups. There are two solutions to this
problem :
Server based data : force users to work on a folder hierarchy that is setup on
the Server and is secure, so that no other person than the specific user can
access such a hierarchy. This is a safe process. However, it does present an
additional load on the network since processing requires data traffic with the
server.
Locally based data that is regularly backed up : users can be shown how to
concentrate all their data in one main folder hierarchy on their own PC. On a
regular basis, scripts can be prepared to push that data from the local folders to
secure folders on the Server. This is more efficient in terms of network traffic but
is slightly more risky as the data is as fresh as the most recent backup.
4) Rotational Backup : ensure that there is a daily backup for all operational data
that is stored on separate media so that there is a tape for Monday, one for
Tuesday, etc. These can be rotated during the next week.
Once a week, prepare an end of week tape separately for each week in the
month. These can be rotated during the next month.
Once a month, prepare an end of month tape separately for each month in the
year. These can be kept as archives.
The above scheme therefore requires :

7 daily tapes that can be reused
4 weekly tapes that can be reused
12 monthly tapes for each year
Of course, some Departments may consider the above too risky and would need
to establish daily or weekly backups that are rotated less frequently. Some may
even require hourly backup.
5) Offsite Locations : ensure that duplicate backups made for key periods such as
end of week or end of month or end of key closing periods are stored outside the
site to avoid theft, damage or loss. Usually, it is best to store such off site backup
media with a Bank or a branch of the Department.
6) Media Duplication : often magnetic media spoils with time. It is therefore highly
recommended to include in the above list backups whereby existing backups are
duplicated on other media. Both are then kept in case of need.
7) Media Technology : change in technology is becoming frequent. This can

present a problem. For example : some centers are finding that they have a mass
of 5 inch floppies as a back up only to find that on a specific day, they do not
have a 5 inch floppy drive or that it has not been tested and is not operational.
The same would apply to 3 inch floppies, DAT tapes and CD-ROMs one day.
It is highly recommended that when the ICT Unit feels that a specific backup
media is being slowly phased out of the market (As what happened with the
LSI-120 disks), that all backed up data gets migrated onto more popular media.
8) Automating Backup : there are products in the market that automate the tasks
of Backup with such features as : scheduling, tracking, incremental backup, etc.
It is recommended that such software be used.
9) Mirroring : disk systems can be duplicated to allow the system to use mirroring
of data. Furthermore, the RAID technology allows such mirroring with the facility
of hot swapping in case of breakdowns, etc. This is also recommended.

Activity 42 : Protection Against Viruses
Objectives : viruses are increasing in their damaging capability as well as the way they
carry out such damages. The aim of this Activity is to provide Good Practices that reduce
the problems associated with Virus infection to a minimum.
Risks : virus can corrupt data, stop access to systems, wipe out files and cause system
slow down. In web sites, they may create a denial of access to the site or even redirect
traffic.
1) Backup : one of the best insurance schemes against infection is proper data
backup. This includes all operating or application software. Review the earlier
activities in this Section for a discussion of backup procedures.
2) Use up to date anti-virus products with the latest patches and upgrades.
These have to be licensed to run on the various machines in the center.
3) Use up to date virus definitions : ensure that a responsible person regular

checks and updates the data definitions of the viruses. Many centers wrongly
assume that if they have the latest version of the software, they are protected. It
is estimated that 200 new viruses are identified per month. Developers of
anti-virus products frequently release new virus definitions to meet this surge.
4) System scans : on a regular basis, scan the whole system including zipped files.
This can be carried out at night when there is no work load on the system.
5) Importing data into the site : in the sites where there is a lot of traffic of data
to and from the outside world, it may be required to implement strict techniques
about using data on floppies or CDs or zip drive disks coming from the outside.
Some centers disable all such units. Others remove them completely. In the case
where a center cannot remove a CD drive because of its internal use, it becomes
critical to discipline users to scan CDs for viruses before using them.
6) Virus hoaxes : even though there are many virus hoaxes, it is better to be safe
than sorry. Stories should be believed until proven innocent. There are several
sites on the web published by the major anti-virus developers that list the hoax
viruses. Virus warnings sent by mail should be checked against these sites. Here
are some examples :
http://www.europe.f-secure.com/news/hoax.htm
http://vil.nai.com/VIL/hoaxes.asp
http://vil.mcafee.com/hoax.asp?
These and other sites will also list real viruses and explain what their effect is and
they can be treated.

8.0 Information Integrity : Business Continuity Planning
Force Majeure situations may occur and disrupt business at the Department over periods
of different lengths. Such situations as the following can cause disasters :
• Civil strife
• Lack of access due to security reasons
• Flooding or water seepage
• Total electrical failure
• Construction damages
• Extreme weather conditions
• Chemical or toxic gases
• Etc
Whatever the case the Department’s ICT Processes should guarantee that there is a
continuity of the Department’s business by setting up countermeasures to such failures
and disasters.
8.1 Business Continuity Plans
Such plans should be available to describe how the Department can continue to operate
in the event of its ICT Systems not being available. The Plans should include :
Contingency procedures as well as Disaster Recovery procedures.
1) Disaster Recovery Procedures describe how the Department can obtain

alternate ICT resources in the event of the primary systems being unavailable.
These procedures would be followed if the system is to be down for longer than
manual procedures could feasibly be used. Disaster Recovery Procedures are
described in the Activity 43 : Disaster Recovery Procedures and Activity 44 :
Disaster Recovery – Good Practices.
2) Contingency Procedures describe how the functions provided by the system

can be performed manually in the event of the system being unavailable.
Contingency Procedures are described in the Activity 45 : Business Continuity –
Contingency Plans.
8.2 Classifying Disasters
The recommended solutions cover different types of disasters. Departments may modify
these terms to suit their own "urgencies". The following Activities provide Procedures
and Good Practices for the following types of interruptions :
1) Stoppages within the center that result in an interruption of a few days. Such a
stoppage is short enough not to require relocation of the total system.
2) Stoppages that result in indefinite interruptions or interruptions that have an

unknown resumption time. These can be further sub-classified as follows :

Small sites
Non-critical sites
Medium sites with large operating volumes
Sites that are semi-critical

Mission Critical Sites no matter how large
The Guide will provide three main Activities to ensure Business Continuity by grouping
the above 5 types of sites into 3 groups. Notice that the first type of stoppage is
considered non-critical and will be considered as part of the first group :
Small and Non-Critical Sites or Short Stoppages
• Non-critical sites that operate batch based applications

• Non-critical sites that solely use office technology products.
• Sites that do not operate in real-time
• Sites that do not have external users such as private sector companies, citizens
or banks.
• Semi-critical or medium sites as in the next Activity but only in the case where
the stoppage is known to take less than is justifiable for a full disaster recovery.
Medium and Semi-Critical Sites
• Semi-critical sites that operate with central applications

• Sites that may operate in real-time
• Sites that do not operate in real time but have short cycles such as daily closing.
• Sites that have external users such as private sector companies, citizens or
banks.
Mission Critical Sites
• Sites whose interruption is considered to be a disaster

• Sites whose users are in the public domain : citizens, private companies,
overseas users, banks, etc.
• Sites that have real time operations that depend on minute by minute up to date
information
• Sites that depend on the Internet for their processing.
In determining the appropriate solution, the Department must analyze their

requirements in the case of a disaster. The analysis must consider up front costs,
maintenance costs, Department inconvenience, and recovery time. The solutions
provided below range from a cost effective to a mission critical solution.

Activity 43 : Disaster Recovery Procedures
Objectives : there is a variety of situations that can be considered disastrous depending

on the criticality and the size of the site in question as well as on the nature and duration
of the distaster. When a disaster takes place, the Department has to move to an
Alternate System. This is called the Recovery System. All software and data will be
recovered on such a system. However, there are different ways of acquiring such a
system depending on the classification of the disaster defined at the beginning of this
Section. This Activity presents a general procedure for dealing with the recovery from
disasters.
The following are broad steps to be followed depending on the size of site and criticality
of that site :
Recovery Systems for Small and Non-Critical Sites
1) Acquire another similar system. This may take time.

2) Recover all software and data
3) Resume operations
Recovery Systems for Medium and Semi-Critical Sites
1) Prepare an agreement with another center a distant from the current site so that
the equipment in that center can be used in emergency situations.
2) Recover all software and data
3) Resume operations
Recovery Systems for Mission Critical Sites
1) On a regular basis, take a Checkpoint backup and restore it on the Recovery

System in anticipation of a disaster. Being mission critical, Checkpoint backup
may be very frequent, say twice a day. (Review the start of Section 7.0 :
Information Integrity : Backup / Archiving and Data Protection).
2) Acquire a mirror system through purchase or agreement with a third party for use
in such situations. The system need not have the same capacity as the current
system. Minimally, it should be able to run the mission critical applications.
3) Install the software and ensure that the operating environments are compatible.
4) In an emergency situation, the Department can resume its work from the latest
Checkpoint.
Note : in the following discussion, the Guide will not differentiate between the above
choices but will present a generic Disaster Recovery Procedure or Plan for all types.
Standard Operating Procedure
The Minimal Requirements for Recovery are :

1) Prepare the following documentation before the Disaster :
Emergency Procedures : describes the immediate action to be taken following

a major incident which jeopardizes business operations. Such actions are usually
not ICT related and would cover such activities as : moving files or special
equipment, ensuring personnel get to the new location, moving support to the
new location, informing external users such as citizens or companies of the
change, etc.
Responsibles : specify the individuals responsible for executing each component

of the plan.
Configuration : prepare a document that describes the configuration of the

recovery system to avoid reconfiguring such elements as user names, passwords,
directory structure, service packs, etc.
The Recovery Procedure : a document that describes the Recovery Procedure

in a step by step fashion.
The Recovery Test Plan : a document that shows the procedure needed to
certify that the Recovery has been properly executed. For example, the Test Plan
can include :
File counts
File sizes
Tests on various reports (Transaction listings, etc)
Database record counts
Date checking
Etc
Related Documents : other documents prepared by related activities such as

Security lists, Backup Registers, etc.
Keep the above documents ready outside the Department so that they can be
immediately accessed in the case of Disaster.
2) Prepare whatever is necessary to ensure access to a Recovery System as

selected for the particular site from the choices presented at the beginning of this
Activity.
Note that even if agreements exist for such systems, the organization in question
might also be under the same disaster, so it is preferable to have recourse to
more than one such site.
3) Backup Media : prepare an offsite location for the backup media. It is

recommended that the media be stored at a significant distance from both the
Production and the Recovery environment in order to avoid total loss in the event
of a widespread disaster. It is vital that the backed up media can be accessed in a
hurry, so again, it is best to have recourse to multiple backups in different sites.

4) Disaster Specific Backup : on a regular basis, take a back up of the full
system. The point at which the backup is taken is called the Checkpoint. Backups
at Checkpoints should be “operation ready”. This means that all the Operating
System and the related software tools should be backed up in a recoverable form
to avoid re-installation in the new recovery site. (Note that this is not the same as
the regular data backup taken by most Departments).
The frequency of such backup should be commensurate with the time of stoppage
that the Department can afford. For example, if the Department is worried about
interruptions that may last more than 1 week, then the backup should be taken
at least once a week, preferably on daily basis.
Recovery Procedure
1) Setup the new Production environment according to the documented Recovery

Procedure.
2) Restore the backed media from the latest Checkpoint.
3) Conduct a test of the recovery procedure as per the Test Plan prepared earlier.
4) Inform all users as to when they can start in the sequence of their work. This
totally depends on the most recent restoration of the data.
5) Open access to users.

Activity 44 : Disaster Recovery – Good Practices
Objectives : the previous Activity presented a procedure for handling the recovery from
disaster by preparing alternative systems. This Activity supplements the previous
Activity by presenting good practices to be followed when handling such situations.
The following Good Practices are suggested as a support to the Disaster Recovery
Procedures of the previous Activity
1) Outsourcing : the major servers needed as Recovery Systems may not always
be available within the Department. Indeed, in some cases, it has been known to
resort to such systems outside the country. Therefore, any outsourcing to be
made to have access to such systems must be submitted to rigorous qualification.
Furthermore, it is critical to regularly test the alternate site to ensure that the
Recovery System is ready for operation.
2) Testing : as in the case of Backup, Disaster Recovery is a kind of a “Restore”

operation. Therefore, it is crucial to test the Recovery on a regular basis by
simulating a disaster.
3) Insurance : not all problems generated by the Disaster can be resolved by a

Disaster Recovery Procedure. A lot of cost and effort is required to setup of a
Recovery System :
The increase in backup frequency

Repeat work that is lost during Emergency and Recovery
Replacement of equipment
Additional running costs such as transportation, relocation, data entry, etc.
Outsourcing of servers, sites, etc.
It is recommended that such activities be insured so that the Department can

recover parts of its losses.
4) Training drills : an emergency is sue to have people lose their heads. It is

therefore crucial in semi-critical and critical situations to have training drills on
Emergency and Recovery Procedures.
5) Risk Analysis : much of the cost and time loss of the Disaster Recovery can be
avoided by a rigorous Risk Analysis of such situations. Ensure that Disasters are
included in the Risk Events to be analyzed in the Department.

Activity 45 : Business Continuity – Contingency Plans
Objectives : as an insurance against the possibility that a system may not be available
for any reason, it is essential to have recourse to Manual Operating Procedures.
Technology being addictive, most organizations forget how to process their work in a
manual fashion and end up losing time and money in case Disasters take place. The aim
of this Activity is to prepare a procedure that defines how Manual Operating Procedures
can take place in case the ICT Systems are not available.
1) Prepare a Procedure for each of the information processes within the system. For
example, Entry of project data is one such procedure.
2) The Procedure will generally consist of the following structure :
• Define the reports that define the status of the data at specific
checkpoints.
• Identify the transactions through their manual vouchers
• Define the procedure used to update the data manually and check it
• Define the procedure to be used upon re-starting the system
3) On turning into the Manual procedure, follow the steps of each of the above
procedures.
Example : the following is a typical procedure for the Maintenance of the Vehicle Fleet in
the Ministry of Public Works :
Prerequisites : a daily list showing all vehicles with transactions on each starting from
the beginning of the month. There will be a list identifying the following vouchers :
change of location, change of department, entry of petrol usage, entry of distance
counter, change of vehicle particulars (Color, chassis, etc), entry of maintenance
summary, etc.
1) Prepare the Vehicles list from separate media
2) As each voucher is received, then manually update the statement by adding one
line by hand showing the specifics of the particular transaction.
3) In case cumulative totals are required such as in the case of Maintenance Costs,
these can be computed on the hard copy report.
4) On a weekly basis, prepare a summary list of all totals (In the above case, only
the accumulated costs).
Upon resuming the system, the operators can re-enter the data directly from the
manually prepared transaction histories.
Documentation and Deliverables : all manual procedures.

9.0 Software Application Development
Throughout the past 30 years, the ICT industry has been plagued with problems that
were and still are mostly caused by poor software. The basic reason is simple. The
Software Technology is still young and has not had the chance to develop a standard
methodology for architecture and contracting, as was successfully done in the
Construction Industry.
Some of the major Problems with Software Processes :
1) There is no clear separation between Architects or Designers of systems and the

Contractors, or the Software Developers of systems. It is known that some
companies do both resulting in inefficient projects and software.
2) There is no standard and efficient Business Modeling language that allows

Software Developers to “draw” their systems in the manner that Architects draw
their buildings and bridges. This leads to communications problems and hence
disputes.
3) Project Management principles are still not being applied
Software Development Processes (SDPs) have started arising and as is normal in such
situations, there are many competing processes.
This Section covers a variety of issues relating to Software Development. It points to a

document that describes SDPs in full that can be downloaded from OMSAR’s web site.

Activity 46 : Using a Software Development Process
Objectives : Most ICT Units suffer from not having a defined and documented Software
Development Process (SPD). Suppliers delivery customized software applications to the
Department may suffer from a similar shortcoming. Selecting and adapting an SDP is not
a simple matter. The Guide will not present such a procedure. However, this Activity will
define software development processes, emphasize their importance and provide
guidelines on how to select them.
Scope of usage : this covers any software development effort whether for :
1) Internal Usage : when a Department wishes to develop its own software

applications, it requires to select and use an SDP OR for
2) Usage by Suppliers : when a Department wishes to investigate the SDP that a

supplier who develops software applications uses. This is presented in the Activity
19 : How to Audit or Qualify Suppliers.
Background : a Software Development Process (SDP) as defined as :
A method whose objective is to plan, execute, monitor and

control the development of software products from the stage
when such products are conceived as basic concepts up to the
point where the developed products are delivered and certified
as operational.
It is critical to note that SDPs are called “Processes”. This is to emphasize that they are
not simple step by step “Procedures”. Indeed, many have failed in the past because they
were forced into tight waterfall “Procedures”.
Risks : not using a Software Development Process may result in the following risks :
• Non standardized approach to programming and development

• Lack of reuse of components
• Poor and nonstandard documentation
• Inefficient project planning
• Inefficient life cycle phases : poor requirements analysis, business analysis,
design, testing and other activities.
Why the Guide cannot recommend a single SDP?
The reasons for not providing a recommendation are the following :
• There is no standard internationally accepted SPD that can be recommended

• Describing typical SPDs requires extensive discussion
• Different applications may require different SPDs
• Different development platforms may require different SPDs

• SDPs require discipline and are hence more than just a Standard Operating
Procedure. They may require training, supervision and monitoring to get properly
implemented as well as adaptation.
• As the technology changes, SDPs change. A case in hand is the emergence of the
Internet which caused a revision to many standard development processes.
With the above restrictions, the Guide will neither be able to recommend a specific
Standard Operating Procedure for an SDP nor provide a set of Good Practices for one.
1) It is important to recognize that SDPs are either commercially available products

or are products that may be learnt from various academic resources such as
books and web sites. The Department needs to research both areas for a proper
SDP.
2) SDPs must have characteristics :
• A methodology that follows a Project Plan and not just tips and techniques
for development.
• It must rely on Modern Project Management practices
• Be based on a modern modeling scheme so that the documentation across
its phases is visual, simple and accepted internationally
• The SDP must not have a strict waterfall approach. The waterfall method
of analysis, design, development, testing and implementation must be
avoided. The alternative is a two dimensional approach where the phases
correspond to those of a modern project as discussed in the Project
Management Institute’s site at www.pmi.org. Within each phase, there will
be a variety of processes such as analysis, design, building, testing, etc.
• Documentation must be a high priority for the process.
• Reuse of components
• Must be flexible and it must be subject to reconfiguration so that it can be
used in different environments.
• Platform and development language independent
• Application independent
• Rely on horizontal Teamwork as opposed to Hierarchical structures
• Iterative and incremental Development
• Efficient and Quality controlled Requirements Management
• The use of Component Architecture
• Traceability of models
• Relies on Risk Management
3) Selecting the SDP must submit to the same procedures presented in Activity 49 :
Selecting Software Applications.
4) Once an SDP is introduced, special effort must be put on maintaining its practices
as planned. Various organizations fall into the trap of applying an SDP only to
start drifting from its standardized procedures.

Activity 47 : Software Development Tools
Objectives : various development tools and platforms (Database systems) can be used
to assist the software development process. This Activity highlights the importance of
using such tools. It also presents some of them and emphasizes the need to justify them
operationally and financially.
Scope of usage : software tools are needed to support the Software Development
Process selected by the Department.
Risks : not using the proper software development tools would result in the following
risks :
• Delays and increased development costs

• Reduction of the quality of the development process and the software itself
• Using the wrong tools would also result in inefficiencies and higher costs
• Using tools that are not standardized across the Department will result in
inefficiencies and higher costs
• There is a risk of not using tools if those selected are too advanced and require
extensive training
1) Here is a list of such tools (Presented under generic titles)
CASE Tools
Integrated Development Environments
Commercially available libraries of components, routines, etc
Business Modeling tools
Source code repositories
Debuggers
Automated testing systems
Commercially available Software Development Processes
Help file generators
Code generators
Report generators
Data warehousing and OLAP tools
2) The Department should select the products that it requires and present a
justification for their acquisition. The justification should be documented.
3) Proper training should be had of all such tools otherwise they will not be
efficiently used.
4) Tools that enforce a standard must be widely utilized as the tools would have a
negative impact if part of the Department does and the other part does not use
them.
5) It is often possible to acquire trial or evaluation products that can be used and
tested before purchasing them.

Activity 48 : Programming Standards
Objectives : with the large number of development platforms, and due to the hurried
nature of development itself, the development profession has not been able to
standardize its work. There are many reasons for this shortcoming that the Guide shall
not go into. However, the Guide will recommend a set of Good Practices that serve to
establish programming standards.
Scope of usage : the scope of this Activity is not limited to one development platform
but is presented as a generic set of practices to be setup for each.
Risks : having poor or no standards will result in the following :
• Code that cannot be understood or even read by others

• Code that is difficult to debug and test
• Code that is difficult to reuse
• Duplication of effort, variables, file names, etc.
• Code that may result in technical hitches, system crashes, hangs, etc.
• Code that may produce errors and bugs
1) Study the development platform under use and establish Programming Standards
that apply to it.
2) Publish the standards and ensure compliance with them. This can be carried out
by frequent checking, dry testing and code review.
3) The following are the areas that need to be addressed when setting up a
Programming Standards document. Review web sites and academic material for
work already done in these areas, especially if a specific development platform is
in use :
• Access to Hardware
• Argument Passing
• Comments
• Data Declarations
• Defining Constants
• Documentation
• Error Handling
• Function Declarations and Returns
• Function Layout
• Including Files
• Modular Coding
• Module Layout
• Naming Files
• Naming Variables
• Source Code Formatting
• Standard techniques and algorithms
• Style consistency
• Version Control

• Using objects
4) The Department should use source code repositories. These have the following
useful features :
• Librarian control on individual modules to avoid them being modified by

different coders at the same time.
• Allows development by teams
• Facilitates version tracking
• Tracks modular and reusable code by sharing files between projects
• Provides security on source code access
Such products as Microsoft Visual SourceSafe™ are typical of source code

repositories and can even be used for a variety of other work such as storage of
project documents, specifications, office technology documents, spreadsheets,
etc.

Activity 49 : Selecting Software Applications
Objectives : when selecting software applications, a methodology should be followed

different from the selection of other information resources such as equipment and
networking items. There should be a logical and manageable progression through the
selection process in order to stress on making the selection process Quantitative rather
than Qualitative. This Activity presents a Standard Operating Procedure for the selection
process.
Scope of usage : covers the selection of all types of software applications and tools.
Standard Procedure :
1) Document Requirements : this is part of the design process. Qualifying the

design so that the Department has the proper Specifications was discussed in
Activity 23 : Specification Qualification (SQ) and as such, should be followed
during this first step. Without a proper specification of the requirements needed
from the specific software, the selection process will be faulty.
2) Research Possible Vendors : this is a multi-step task. It depends strongly on

the procurement procedures of the Department and of the project in question.
Briefly, the Department can use the recommendations of Activity 19 : How to
Audit or Qualify Suppliers to start with a Long List and progressively reduce it to a
Short List of Suppliers that can supply the required software product.
3) Create and Issue RFP : where the RFP must include all relevant sections
discussed earlier in Activity 22 : Recommended Issues to Consider in ICT
Agreements. Especially important is the presentation in the RFP of the basis of
the evaluation scheme to be used to select the supplier and the product.
4) Create and Issue Demo Scripts : on receiving the proposals, and part of the
evaluation of the products, the Department must issue scripts to be used in the
demonstration of the products. These are test and evaluation scripts that will
verify that each of the functions stated in the design or specifications is part of
the product and is working as expected.
Demo scripts should include such items as scenarios to demonstrate, sample

date, evaluation criteria and expected results.
5) Visit other user sites : one of the most efficient means of analyzing software
products is to view them under actual usage. This exercise also confirms that the
supplier has already installed the product elsewhere and that as such, he has the
proper experience in supporting the product.
6) Analyze Proposals : the Department needs to subject the proposals to a

disciplined evaluation scheme as described in Activity 21 : Evaluation of
Suppliers, Products, Projects or Alternatives. This will assist the Department in
the task of converting qualitative scores into a single quantitative score based on
which the selection can be made.

6) Select Vendor/Software : upon arriving at the best score, the Supplier will be
selected and will hence go into a negotiations phase where the final drafting of
the agreement takes place.
7) Project Plan : in parallel with finalizing the draft agreement, the Supplier and
the Department must prepare a final Project Plan for the acquisition, installation,
operation and performance testing of the software product. The plan must be
subject to the criteria established in the various Qualification Processes :
Installation, Operation and Performance Qualifications discussed in Section 4.0.
1) Software specifications
2) Evaluation criteria and weights
3) The request for proposal (RFP)
4) Demo or test scripts
5) The test results
6) The evaluation results
7) The implementation project plan
Acceptance Criteria : upon the submission of all the above documents, the Activity can
be considered complete.

10.0 Operations Management
The Appendix of Supplementary Material of this Guide discusses the structure of

typical ICT Units. One of the major functions in such an organizational structure is that
of Operations. The function of the Operations Unit within the ICT Unit was stated as :
“A unit that has the responsibility of seeing all work and

operations processed by the ICT Unit completed according to
the highest possible quality level. Operations include regular
data processing as well as some user based work”.
There are various Procedures and Good Practices that should be followed by the
Operations Unit to meet the above objectives. The functions of this Unit were clearly
stated in the Appendix of Supplementary Material. Therefore, in this Section, the
Guide shall not repeat the functions of data entry, data flow, etc.
The Activities that follow cover some procedures related to the Operations Function. The
following Section covers procedures related to the Data Entry functions.

Activity 50 : Logging Maintenance and Support
Objectives : one of the main causes of disputes between the following parties is that
lack of coordination on Support and Maintenance : users, third parties supporting or
maintaining systems, Suppliers and the ICT Unit. This Activity presents a procedure that
defines the means of logging all support calls for the purpose of tracking, analysis and
control.
Scope of usage : the procedure covers :
• Maintenance of hardware, software and networks

• Support of hardware, software and networks
• Application support for users
Risks : not having a register will lead to lost calls, improper traceability and reduced
analysis of problem causing areas.
Prerequisites for the Standard Operating Procedure :
1) Valid users : establish a list of all persons who can call regarding Maintenance
and Support services. Persons outside this list should either be considered for
inclusion or given special lower priority treatment.
2) Valid items to maintain or support : establish a list of all items that can be
supported. Items outside the list should either be considered for inclusion or
given special lower priority treatment. (This could be linked to the Configuration
Management database).
3) Maintenance and support request form : prepare a printed form or an

automated form. The latter can be a centralized application, an email form or an
intranet web page. These can be used by users to log in their medium to long
term problems.
Maintenance and Support Logging Procedure
1) Each call should be registered or logged on the selected media : printed form,
email, intranet web page, application, etc.
2) The Maintenance and Support Request form should contain the following data :
Time/Date
Name of User / Department
Type of call (To be entered by the user and later modified if need be)
Description of problem
Priority (To be set by the user)
Expected date for completion (To be set by the user)
3) The Calls should be processed by support staff who can tell which one is to be
support by which unit. They will then be routed accordingly. During routing, the
support person can enter the receiving party’s name on the form.

It will be the responsibility of the Support or Maintenance person to process the
Change Request if there is reason to change the Configuration.
4) External Maintenance or Support : in case these are to be supplied by

Suppliers outside the Department, it will be the responsibility of the Support
person to liaise between the User and the Suppliers. Suppliers will receive copies
of the Request and will act accordingly.
5) The support person will then review the situation, visiting the user if need be. On
completion, the following is entered on the call form :
Time/Date started processing the call

Time/Date completed processing the call
Real problem : as the user may have phrased the problem wrongly, the support
person will enter the actual cause or issue of support.
Action taken : describes what was done to solve the problem or give support
6) In case the call is being handled by a Supplier, then the Supplier must complete
the call and fill in some of the information above.
1) A list of the valid Users

2) A list of the valid Items to Maintain or Support
3) The Call Form
1) Since users generally consider all their problems as high priority, it may be a
good practice to prepare a Help Desk that filters these calls, directing the user to
note down his or her problem on paper or electronically if that problem is judged
to be of medium or low priority.
2) Whenever there are changes to the Configuration, these should be posted onto
the Configuration Management database by the person completing the
Maintenance or Support Request.
3) On a regular basis, the Requests should be analyzed to arrive at such analyzes as

the following :
Most frequent calls by :

Type of call (Repair, preventive maintenance, queries, bugs, etc)
Department or Unit or Division
Equipment
Software
Networking components
Site items
How does training vary with the frequency of calls?
What is the average time between the following :

Time request placed till it was handled
Time request started getting handled till it was cleared
In how many cases did the request cause system stoppage?
Etc

Activity 51 : Control Dissemination of Hard Copies and Distribution
Objectives : one of the major responsibilities of the Operations Department is the

dissemination of the information being processed by the various systems. More and
more, such information is being converted from paper form to screen displays. However,
there is a need to plan and control such dissemination. The objective of this Activity is to
prepare a Procedure that allows the Department to plan the distribution and
dissemination of reports applying security whenever this is crucial.
Scope of usage : all displays and reports are included in this Procedure. Moreover, with
the popularity of exporting data from various databases for use on local employee
stations, such data is also included.
Risks : not being able to control the dissemination of hard copies may lead to the
following risks :
• Lack of security
• Overproduction of reports
• Storage of paper reports instead of on electronic media leading to loss of space
1) Prepare a list of all reports, major screen outputs and exported data
2) Define the frequency of the reports when they are cyclical. The rest can be
produced on request.
3) Prepare a list of all users and which reports they should receive
4) Configure the system so that user can print on specific printers.
5) Establish security levels required for :
The production of the reports

The viewing of the screens
The exporting of the data
6) The Reports Distribution List : by now, the Operations Unit would have a list
of all reports to be produced for which user and at what frequency.
As this list, produce the reports where it is the responsibility of the Operations
Unit to do so, otherwise, that is left for the user.
• The Reports Distribution List

1) Electronic Storage : in the past, it was always the case that reports should be
produced for auditing and checking purposes. With more reliable software, it is
recommended that users should be store reports in electronic format on their
individual PCs. This would save in printed paper and time of production.
Here, it may be beneficial for the Department to resort to the use of COLD
technology (Computer Output on Laser Disk). This technology converts any report
being sent to a printer into an Acrobat Reader PDF or ASCII text mode in an
electronic format providing a variety of search services, annotations, etc.
2) Report Generators : more and more, Suppliers are supplying “report

generating” software along with database structures. This generally makes it easy
for users to prepare reports directly from the database. Although of great benefit,
training is required for this practice. Without proper training the following two
risks may be faced : by using wrong fields or wrong conditions on some of the
fields, users may produce reports that are not valid. Secondly, users may create
queries that are massive which would create heavy loads on the system.
3) Export Data : when systems are being designed, it is recommended to select

some of the reports and allow them to be exported in spreadsheet format.
General software applications are not capable of charting, sensitivity and
statistical analysis. By allowing the data to be exported in such format, users can
manipulate the data using standard spreadsheet products.
4) Security : sometimes reports have part of their data that needs to be secured.
For example, an inventory list in the Municipality’s Vehicles Maintenance
Department should be viewed by anyone. However, not anyone should be able to
review the cost prices. Therefore, the design should cater for such security checks
at the data element level.
The Reports Distribution List should be approved by the Management of the Department
before any reports are released.

Activity 52 : Good Practices for User Support
Objectives : with the spread of Office Technology, User Support is currently a wider
function than simply that of supporting an application. The Support Unit is described in
the Appendix of Supplementary Material. The objective of this Activity is to present a
set of Good Practices for the Planning, Execution and Control of User Support.
Scope of usage : all types of Users :
• Management
• Technical and Operational Staff
• Users accessing the system from outside the Department (Citizens, companies,
etc)
The support is for all types of applications and requirements :
• Hardware : its fault reporting, usage, preventive maintenance and installation

• Office Technology Applications : usage, installation, upgrades, updates,
configuration and error reporting.
• Telecommunications : connections, installation, configuration fault reporting.
• Running specific applications of the Department.
Risks : not having proper user support may lead to the following problems :
• Inexperienced users handling their own problems

• Inexperienced users assisting others because of slightly higher experience
• Lack of procedure for analysis of support calls
• Lack of user training will lead to increased calls for support
• Improper Installation, Operation and Performance Qualification will lead to
increased calls for support.
1) Ensure that the Procedure defined in Activity 52 : Good Practices for User Support
is setup for logging Support Calls. This is useful to track calls and follow them up.
When analyzed, the types of support calls direct the Department towards the
solution of the problems causing these calls.
2) Ensure that Users are properly trained in all products that they use. It has been
regularly shown that properly trained users translates into a major drop in the
volume and criticality of support calls.
3) Encourage Users to resort to Help Files and user Documentation. This would also
translate into a drop in the volume of support calls.
4) Automate parts of the support. This applies to the following :
• Network Management Software that analyzes all components on connected

PCs on a daily basis. This supports Configuration Management and enhances
the knowledge of the Department about what each PC contains.

• Provide users with Intranet or application based logging of support calls on
issues that are not urgent.
• Ensure that all software installations are carried out by system support
personnel.

Activity 53 : Managing the Supplies of the ICT Systems
Objectives : to present a set of Good Practices that allow the Department to better
manage the supplies needed for the various ICT Systems. Essentially, these aim at
ensuring that supplies have the right quality, capacity, standard and availability.
Scope of usage : supplies can broadly be grouped as follows :
• Paper products : blank paper, preprinted computer forms, preprinted vouchers,

computer labels, boxes
• Magnetic media : tapes, diskettes, zip drive media
• Backup media : CD-R, CD-RW and DVDs
• Ink : cartridges, toners, etc.
• Stationery
• Backup spare parts such as printer heads, floppy drives, power supplies for PCs,
modems, hubs, hard disk units for PCs, etc
1) Itemize the required supplies. Establish their technical specifications according to

the systems in use.
2) Define the expected usage for the next period (Usually, one year).
3) Survey the market and qualify the Suppliers and their supplies.
4) Follow the Department’s procurement policies to acquire such material.
5) Prepare an inventory management scheme with an issuing policy so that there is

a complete control on the movement of such items.
6) On a regular basis, analyze the above inventory to ensure that there is enough
material to avoid shortages.
1) Some supplies have special storage requirements which should be observed. For
example, some computer continuous forms should be stored in computer rooms
to avoid humidity which may cause paper jams. Magnetic media should be stored
in areas that are protected against interference.
2) Pay special attention to Backup Media Control. Shortage of such media can be
most damaging.
3) Link of supplies to Configuration Management.

Activity 54 : Documenting Data Entry Procedures
Objectives : generally, most work done on improving the standards of data entry
covers the entry of data for operational, financial or administrative applications. These
are either developed for the Department or acquired as Commercial products. This
Activity presents some Good Practices for ensuring that all data entry procedures are
properly documented.
Scope of usage : generally, this would apply to data entry for operational,
administrative and financial application software. However, in some cases, there are data
entry procedures that are covered by Office Technology products.
These latter are discussed under the

Activity 56 : Using and Supporting Office Technology Products later on in this Section.
Risks : not having proper data entry procedures would lead to the following :
• Improper entry of data causing errors, rework and possibly damages with citizens
and other users of the data.
• Erroneous or slow entry of data leading to loss of time and re-entry
• More rigorous training of new staff
1) For each data entry form in each software application, a detailed Data Entry
Procedure is to be prepared. Generally, the software would have such procedures
if it is well documented. In such a case, the Department should check if such
procedures are sufficient, otherwise, they would be used as the basis for a
redeveloped Data Entry Procedure.
The Data Entry procedure would be used in the following cases :
Training
Day to day entry tasks
Validation and consistency checking
Auditing purposes
Refreshing the user
A Sample Data Entry Procedure is presented in the Appendix of

Supplementary Material.
2) On preparing a Data Entry Procedure, it should be tested to ensure that all data
elements are clearly explained and that the procedure is easy to understand and
use.
3) Whenever the Department is developing its own systems or requesting such

systems to be developed by third parties, it is essential to follow some Data Entry
standards or Good Practices. These are presented in the Appendix of
Supplementary Material.

4) Error analysis should be carried out. When errors are reported, they should be
registered and totaled. If specific forms are found to generate more errors than
others, then there is the possibility that the form is not being properly understood
or that it may have programming problems.
5) Use Audit Trails when possible. Audit Trails are rigorous ways of verifying
proper data entry. Throughout the years, the term got distorted to mean the
following : a list of transactions as entered. This is not correct. Audit trails
technically mean the following. A batch of vouchers is entered. One of its fields is
accumulated manually, say the amount on the voucher. The batch is controlled as
one single group of vouchers by the system. The batch or Audit Trail is entered
into the system. The batch is not updated or posted to the database unless the
computed total equals the entered total. Along with this checking, the system
must be able to produce a validation list of all vouchers before committing the
entry.
6) Data Integrity : various systems are designed without proper data integrity. For
example, there are many Inventory Management systems that allow the quantity
to go negative. There are cases where the accounting vouchers posted from an
operational module do not correspond to the totals recognized by the accounting
system. For example, purchases in the Inventory Management system do not
correspond to the total inventory in the Accounting System. Such areas should be
investigated and checked on a regular basis to ensure that there is Data Integrity.
Documentation and Deliverables : all Data Entry procedures
Acceptance Criteria : data entry procedures are critical and must be validated by the
developers of the software and the users in the related Departments. Upon full validation
that such procedures are corrected, it is recommended that they be tested. They can
then be accepted.

Activity 55 : Standard Data Entry Checks and Controls
Objectives : when developing or acquiring software applications, it is important to

ensure that the data being entered is properly checked. This Activity presents guidelines
for data entry checks and controls.
The following types of checks and controls are important to have in the data entry
screens in all software applications :
• Validate all field that have ranges such as dates or amounts

• Try to increase the number of lookup tables so that users do not enter country
codes or currencies whichever way they wish.
• Allow the user, under privilege control, to add a parameter that is not in a lookup
table on the spot without having to go to another screen.
• Allow the user to search for major tables such as citizens, projects, contractors,
etc. This should be available during deletions, modifications, printing and other
system functions.
• Design screen layouts to be similar to actual vouchers. This eases data entry and
requires less training for the user
• Use clear color coding as per Windows standards : Black labels, White for
enterable fields and Grayed fields for non-enterable or for system responses
• Differentiate between Info, Error and Warning messages through the proper use
of buttons : Info (OK), Error (OK), Warning (Yes, No), Choices (Yes, No, Cancel).
• Use clear and unambiguous messages
• Avoid cluttering the screen with a large number of fields. It becomes difficult to
visually scan the screen and validate the data. In the case of large number of
fields, it is best to use TABs or even multiple screens. For example, the CV
database presented in the Appendix of Supplementary Material can be
presented over two pages with buttons that will show other screens for the entry
of work, education and training experience.
• Do not allow the system to accept to create or modify a record unless all data is
validated. Many systems suffer from temporary entries that are never completd.
The above guidelines should be standardized across various applications to ensure that
users get familiar with the look and feel of applications and hence require less training.

Activity 56 : Using and Supporting Office Technology Products
Objectives : many governmental processes are based on Office Technology Products

(OTP) that are end user programmable. For example, a certain Ministry may use a word
processor to prepare various authorizations or certificates. Another may use a
spreadsheet to prepare budgeting exercises. Should the use of such products not be
organized properly, damages may result and worse still, the products will be
underutilized. This Activity covers a variety of recommendations, many of them related
to standardization of work by the users.
Scope of usage : covers all PC based applications that are used on a stand alone basis
by the users. This covers such products as word processors, spreadsheets, personal
information managers, email, faxing products, illustrators, minor databases, web page
editors and a variety of other office technology products.
Risks : not following good practices in this area :
• Creates a confused environment that is not standardized

• Increases dependence on user support
• Reduces the efficiency of training
• Exposes the Department to data and document losses
• May cause deterioration of network response if not organized properly
1) User Training : one of the most prevalent problems is that of lack of familiarity
with Office Technology Products (OTP) in use. Most products are simple to “start
using”. However, as soon as users hit difficulties, they are on their own without
assistance. This is due to lack of proper training and poor practices. The first step
to ensure proper use of Office Technology Products is to provide regular training
of users.
2) Encouraging use of office technology products : most users will be happy

using 10% of a word processor and a spreadsheet. It does not require much more
effort to improve the competence in such products. However, it is more important
to encourage users to use other products which are not so obvious such as
slideshows (Powerpoint), illustrators (Visio), minor databases (Access), etc.
3) Standardized Directory Structures : most users have a tendency to create

documents all over the disk on their PCs. This usually results in document losses,
duplication and difficulties while backing up. It is recommended that the
Department establish a standardized directory or folder structure that can be
used by all users. This has the added benefit of allowing easier support and
backup.
4) Standardized File Naming : for files that are used internally and between
different users, it is best that a standardized naming procedure is followed. This
may be linked to a reference generator that is setup on a published register. For
example, on issuing a specific type of certificate, the user can open a centrally
accessible spreadsheet, get the next reference, register the certificate on the

spreadsheet and use the reference as part of the file name. Other types of file
naming practices can be introduced such as clear titles, etc.
5) Backup procedures : although discussed in Activity 38 : Backing Up, this

activity is slightly more complex with user data as such data is not centralized nor
standardized. There are different ways to handle backup and all are discussed in
the above Activity. The important issue is to ensure that users are aware of the
need to backup their documents using whatever method is selected as per
Activity 38.
6) Using standard forms : many organizations fall in the trap of using different
forms for their standard correspond and issues. Forms can be standardized and
setup as templates on the user systems or on the central server. Linked with the
reference generating practice discussed above, this would give the Department a
more efficient control of correspondence. Such forms as the following can be
standardized :
• Outgoing general correspondence

• Faxes
• Certificates the Department may issue
• Authorizations the Department may issue
• Various procurement forms such as orders, delivery reports, change
orders, etc.
• Various human resource forms such as leave requests, absence
justification, change of status, etc.
• Invoices, receipts and other financial documents
7) Version Issues : office technology product suppliers often update and upgrade
their products resulting in documents not being compatible between one version
and the next. Often, this causes inconvenience and time loss for users
exchanging such documents. It is therefore important to ensure that all users
have the same versions of office technology products or at least have the proper
converters for such products.
8) Information Sharing : invariably in an office environment, the same

information gets logged onto different PCs resulting in duplicated effort and
incompatible data. It is important to survey the Department to identify such
information and ensure that it is either centralized or that it resides with the
person who is totally responsible for its maintenance. In all cases, it should be
sharable. Such information as the following should be shared : telephone lists,
email addresses, schedule of events, project lists, supplier names and records,
file structure, reference register, document registers, types of templates, placed
orders, etc.

11.0 Environment Management
Most large computer centers require specific environmental conditions so that the
equipment is maintained in proper running order. This is an Information Process that
covers the definition of environmental conditions, the drivers used to maintain such
conditions within the correct operating zones and the testers needed to warn against
such conditions going out of their operating zones.

Activity 57 : Define the Required Environmental Conditions
Objectives : this Activity presents a Procedure that defines the technical specifications
required of the environment of the site where various ICT systems reside.
Scope of usage : the environment covers large computer sites, server rooms,
communications rooms, cabinets, media storage, etc. Equipment is required to monitor
the environment for such purposes as :
• To measure various parameters (Temperature, humidity, dust, etc)

• To warn when such situations arise as excessive smoke, fire, temperature,
humidity, etc.
• To act under certain situations. For example, in case the UPS is not producing the
required voltage to run the system, it may send a signal to the servers to shut
down normally, turning on emergency lamps, etc.
Risks : not knowing what the proper environmental conditions are may lead to
• Building improper sites : either too lax which may cause system problems or too
strict which may require excessive costs.
• Not recognizing that the systems are operating outside their proper operating
zones and hence expose the Department to environment problems
The following Procedure should be prepared with the help of Suppliers, Site Engineers
and in some cases, the architects of the site. It consists of the development of 5 types of
documents :
1) Environmental Factors or Drivers : prepare a list of all environmental factors

to be controlled. Examples such as the following are common :
Temperature levels
Dust levels
Humidity levels
Quality, stability and continuity of power
Radiation interference (Radars, cellular networks and phones, motors, etc)
Smoke levels
Fire
Other gases
A/C quality
Etc
2) Range of Operation : define the ranges allowed for each of the above for the
specific site. These are technical specifications and should be validated with the
Suppliers or the Manufacturers of the Equipment.
These are also critical items since in some cases, insurance, warranties and
maintenance agreements may be voided if the environment is not within its
required limits.

3) Monitoring Equipment : identify the type of monitoring equipment needed to
test the above environmental drivers. Acquire such equipment through the proper
procurement procedures.
4) Monitoring Equipment Test Procedures : develop Test Procedures that can be

applied to the monitoring equipment itself to ensure that it is running properly.
5) Environmental Drivers Test Procedures : develop Test Procedures that can be

applied to the Environmental Drivers to ensure that “in situ” the monitoring
equipment is operating properly providing the right measurements, warnings or
actions.
Documentation and Deliverables : the above 5 lists.
1) Include all monitors in the Configuration Management database for better

tracking.

Activity 58 : Monitor Environmental Behavior
Objectives : to monitor the various environmental factors affecting the environment in

which the ICT Systems operate and to ensure that the environment is maintained
running within its allowable zones.
Risks : having no monitors or faulty monitors can lead to :
• Stoppage of work due to the environment creeping out of its valid operating
zones
• Damage to equipment in the short and long term
• Corruption of data on current and backed up media
• Voidance of warranties and maintenance terms by Suppliers who will claim that
their equipment may have been operating outside their acceptable operating
zone.
1) Ensure that the 5 lists required in Activity 57 : Define the Required Environmental
Conditions have been properly prepared.
2) Ensure that the required monitors as defined in the above lists are acquired on
time and installed according to the proper IQ and OQ procedures presented
earlier.
3) Apply Monitoring Equipment Test Procedures prepared in the previous

Activity at the time of installation and on a regular basis to ensure that they
provide the proper reading, give the right alarms or carry out the proper action.
4) Apply the Environmental Drivers Test Procedures prepared in the previous

Activity to ensure that unusual environmental behavior is being intercepted and
that the proper actions are taken by the equipment.
5) Document all test results.
6) Diagnosis and Remedial Action : in case monitors give results that show that
the various environment parameters are veering out of the acceptable operating
range, the related parties responsible for such systems should be contacted for
diagnosis and remedial action.
For each monitor, both the above tests should be passed.

The ICT Processes

Uploaded by

Document Information

Original Description:

Original Title

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

The ICT Processes

Uploaded by

Copyright:

Available Formats

ICT Processes

Standard Operating Procedures

1.0 Preliminary and Administrative Activities ................................................ 1

The ICT Processes Page 1

Questions such as the following should be asked and answered :

• What is each ICT System for?

Documentation and Deliverables : prepare a document that responds to the above

The ICT Processes Page 2

• Undefined or unclear scope of the Project (Too wide or too narrow)

Standard Operating Procedure :

1) Define the Project Scope, Objectives and Goals.

The ICT Processes Page 3

The functions and features of the Project (Deliverables)

Good Practices and Recommendations : it is always critical to implement modern

Acceptance Criteria : this Activity is considered accepted when a Project Plan is

The ICT Processes Page 4

Standard Operating Procedure :

1) Identify all existing documents that should be used such as :

3) Ensure that all documents are up to date.

The ICT Processes Page 5

• Not being aware of how Risk Management takes place.

Standard Operating Procedure :

Follow the details provided in the Appendix of Supplementary Material of

1) Identify all events which may damage the Project

4) For information’s sake, an impact should also be assessed in terms of the

6) List all Risks sorted by decreasing Exposure

The ICT Processes Page 6

Good Practices and Recommendations :

• New projects are launched

The ICT Processes Page 7

Scope of usage : the scope of the Project.

• Improper implementation of the Project Plan

Standard Operating Procedure :

• The Charter is generally in the form of a memo or a letter by the Management

3) Define the roles and responsibilities of each person on the Project

4) Define the communication level to be established within the Project :

What information to distribute?

Documentation and Deliverables : the documents listed in the above SOP.

The ICT Processes Page 8

The ICT Processes Page 9

Objectives : Performance Measurement is one of the key managerial techniques in the

• Measuring the wrong things

Standard Operating Procedure :

2) Prepare the Metrics for each of these areas. Examples :

• Citizen satisfaction as measured by an index usually prepared through a

3) Measurement Schemes : develop a document that defines how each of the

The ICT Processes Page 10

5) Analyze the measurements on a regular basis for decision making.

Documentation and Deliverables :

Good Practices and Recommendations :

1) It is very practical to use a spreadsheet to record all the measurements. It makes

2) It is highly recommended to use Statistical Process Control procedures (SPC) that

The ICT Processes Page 11

Objectives : ICT goes regularly through phases of confusion followed by

The benefits of complying with standards are the following :

1) To avoid breaches of any criminal or civil law, statutory, regulatory or contractual

2) To ensure compliance of systems with organizational policies and standards

3) To ensure that various standards set by the Department’s Management,

Scope of usage : all Information Processes. Standards may be external standards

Risks : not complying with standards may result in

Standard Operating Procedure :

1) Identify the standards in question. These may be standards such as the