PART 1 IT AUDIT FRAMEWORK

INTRODUCTION
The use of Information and Communication Technology (ICT) within government entities
has become increasingly significant in recent years, particularly following greater use of the
Internet and organisational intranets. Technology has increased the amount of data and
information being processed and it has significantly impacted the control environment. ICT is
also now a key component of government entities business strategies and core business
processing activities. The management of ICT risk has therefore been elevated within entities and
now forms a key part of corporate governance. Accordingly, the effective and efficient
management of ICT is vital to the success of most entities.
As computer technology has advanced, Government organisations have become
increasingly dependent on computerised information systems to carry out their business
operations and service delivery and to process, maintain and report essential information. There
are also an increasing range of ICT vulnerabilities and threats that have to be effectively and
efficiently managed. As a consequence, the confidentiality, integrity, availability and reliability of
computerised data and of the systems that process, maintain and report these data are a major
concern to audit. IT auditors evaluate the effectiveness and efficiency of IT controls in
information systems and related operations to ensure they are operating as intended.
IT AUDIT
IT audit is the process of collecting and evaluating evidence to determine whether a
computer system has been designed to maintain data integrity, safeguard assets, allows
organisational goals to be achieved effectively and uses resources efficiently. An effective
information system leads the organisation to achieve its objectives and an efficient information
system uses minimum resources in achieving the required objectives. IT auditors must know the
characteristics of users of the information system and the decision-making environment in the
auditee organisation while evaluating the effectiveness of any system.
Use of computer facilities has brought about radically different ways of processing,
recording and controlling information and has combined many previously separated functions.
The potential for material systems error has thereby been greatly increased causing great costs to
the organisation. The highly repetitive nature of many computer applications means that small
errors may lead to large losses. For example, an error in the calculation of income tax to be paid
by employees in a manual system will not occur in each case, but once an error is introduced in a
computerised system, it will affect each case. This makes it imperative for the auditor to test the
invisible processes and to identify the vulnerabilities in a computer information system, as
through errors and irregularities, the costs involved can be high.
Increasing use of computers for processing organisational data has added new scope to the
review and evaluation of internal controls for audit purposes. The IT internal controls are of great
value in any computerised system and it is an important task for an auditor to see that not only
adequate controls exist, but that they also work effectively to ensure results and achieve
objectives. Also internal controls should be commensurated with the risk assessed so as to reduce
the impact of identified risks to acceptable levels. IT auditors need to evaluate the adequacy of
internal controls in computer systems to mitigate the risk of loss due to errors, fraud and other
acts and disasters or incidents that cause the system to be unavailable.
NEED FOR IT AUDIT
Management employing the use of information systems have objectives and
expectations of what they intend to achieve from the large investment made in utilising
technology. Reasons for implementing ICT within the organisation include the desire to obtain
business value through reduced costs, greater effectiveness, enhanced efficiency and/or increased
service delivery. It is against these objectives that an IT auditor is required to provide
management assurance. Typically, management’s goals and objectives in utilising technology to
support business processes include:
• Confidentiality;
• Integrity;
• Availability;
• Reliability; and
• Compliance with legal and regulatory requirements.
Underpinning these goals and objectives is the need to ensure information technology, and the
controls supporting such technology, assists the organisation to achieve its business objectives
(effectiveness) with appropriate use of resources (efficiency).
Confidentiality
Confidentiality concerns the protection of sensitive information from unauthorised
disclosure.Consideration needs to be given to the level of sensitivity to the data, as this will
determine how stringent controls over its access should be.Management need assurance of the
organisation’s ability to maintain information confidential, as compromises in confidentiality
could lead to significant public reputation harm, particularly where the information relates to
sensitive client data.
Integrity
Integrity refers to the accuracy and completeness of information as well as to its validity
in accordance with business values and expectations. This is an important audit objective to gain
assurance on because it provides assurance to both management and external report users that the
information produced by the organisation’s information systems can be relied and trusted upon to
make business decisions.
Availability
Availability relates to information being available when required by the business process
now and in the future. It also concerns the safeguarding of necessary resources and associated
capabilities. Given the high-risk nature of keeping important information stored on computer
systems, it is important that organisations gain assurance that the information they need for
decision-making is available when required. This implies ensuring that the organisation has
measures in place to ensure business continuity and ensuring that recovery can be made in a
timely manner from disasters so that information is available to users as and when required.
Reliability
Reliability refers to the degree of consistency of a system or the ability of a system (or
component) to perform its required function under stated conditions.Reliability is an important
audit objective in order to provide assurance that the system consistently operates and performs
its stated functions as expected.

Compliance with Legal and Regulatory Requirements

Compliance deals with complying with those laws, regulations and contractual obligations
to which the business process is subject, that is, externally imposed business criteria.
Management and key stakeholders require assurance that necessary compliance procedures have
been put in place, as there is a potential risk that the organisation could incur penalties should
legal and regulatory procedures not be enforced.
IT AUDIT STANDARDS
 There is wide recognition that the specialised nature of IT auditing and the skills
necessary to perform such audits, require standards that apply specifically to IT auditing. In
response to this need, various professional and government organisations develop and maintain
standards and guidelines for IT auditing.
The professional standards provide a framework for all audits and auditors and define the
mandatory requirements of the audit. They are a broad statement of auditors responsibilities and
ensure that auditors have the competence, integrity, objectivity and independence in planning,
conducting and reporting on their work. The guidelines supporting the professional standards
assist the auditor to apply the standards and provide examples that an IT Auditor might follow to
meet these standards.
In addition to IT auditing standards, IT auditors need to be alert to other laws, regulations,
or other authoritative sources that may impact upon the conduct of an IT audit.
IT AUDIT OBJECTIVES
The objective of undertaking an IT audit is to evaluate an auditee’s computerised
information system (CIS) in order to ascertain whether the CIS produces timely, accurate,
complete and reliable information outputs,6 as well as ensuring confidentiality, integrity,
availability and reliability of data and adherence to relevant legal and regulatory requirements.
Audit objectives will vary according to the nature or category of audit.
The objectives of undertaking an IT audit as a component of a financial statement audit
include to:
• Understand how well management capitalises on the use of information technology to improve
its important business processes;
• Understand the pervasive effect of information technology on the client’s important business
processes, including the development of the financial statements and the business risks related to
these processes;
• Understand how the client’s use of information technology for the processing, storage and
communication of financial information affects the internal control systems and our consideration
of inherent risk and control risk;
• Identify and understand the controls that management uses to measure, manage and control the
information technology processes; and
• Conclude on the effectiveness of controls over the information technology processes that have a
direct and important impact on the processing of financial information.
Where IT audit is involved in the performance audit, the objectives of the audit are further
defined by what role IT is playing in the audit.
• If the performance audit has an IT focus, the objective will be to seek assurance that all aspects
of the IT systems, including necessary controls, are being effectively enforced.
• The performance audit could alternatively be examining the efficiency and effectiveness of a
business process/government program and as such IT audit is involved because IT is considered
critical in the organization being able to deliver those services. As such, the focus of the IT audit
is to provide assurance that the IT systems can be relied upon to help deliver those services. The
efficiency and effectiveness of those services are then examined from a non-IT perspective after
considering the impact that IT has on the ability of the organization to deliver those services.
IT CONTROLS
IT controls involve an entity’s board of directors, management and other top personnel
and are designed to provide reasonable assurance regarding the achievement of objectives in the
categories:
• Effectiveness and efficiency of operations
• Reliability of financial reporting
• Compliance with applicable laws and regulations
IT controls in a CIS include the entire manual and programmed methods, policies and
procedures that ensure the protection of the entity’s assets, the accuracy and reliability of its
records and the operational adherence to the management standards.
The IDKK IT Audit methodology uses a top-down, risk-oriented approach in the
evaluation of controls. The following steps provide an overview of the tasks involved in review
of IT controls:
Phase Description

Planning This phase facilitates the IT auditor in gaining an understanding of

the agency, its organisational structure and operations. The IT
auditor obtains an understanding of the entity’s computer related
operations and controls and related risks in view of inherent IT
risks. From this understanding the auditor evaluates the
overall IT control environment and makes a preliminary risk
assessment. The results of the assessment will guide the extent of
procedures to be employed in subsequent phases of the audit.

Verification and Testing During this phase of auditing, IT auditors obtain detailed
information on control policies, procedures and objectives and
perform tests of control activities. The objectives of these tests
are to determine if controls are operating effectively.General
controls as well as application controls must be effective
to help ensure the confidentiality, integrity, availability
and reliability of critical computer processed data.

Reporting Phase During the reporting phase, the IT auditor draws conclusions
and develops a report in order to communicate the objectives of the
audit, the audit scope, the methodology adopted and the
findings, conclusions and recommendations.

In CIS environment, the control components found in manual systems must still exist.
However, the use of computers affects the implementation of these components in several ways.
IT controls are used to mitigate the risks associated within the IT environment and application
systems and are broadly classified into three categories. These controls are part of the overall
internal control process within any auditee’s organisation:

• General Controls
• Application Controls
• Specific Controls
General Controls
 General controls include controls over data centre operations, system software acquisition
and maintenance, access security and application system development and maintenance. They
create the environment in which the application systems and application controls operate.
Examples include IT policies, standards and guidelines pertaining to IT security and information
protection, application software development and change controls, segregation of duties, business
continuity planning.IT project management, etc.
General IT controls are concerned with the auditee’s IT infrastructure, including any IT
related policies, procedures and working practices. They are not specific to individual transaction
streams or particular accounting packages or financial applications. In most instances the general
controls elements of an IT review will concentrate on the auditee’s IT department or similar
function.
Categories of general control include:
• Organisation and Management (IT policies and standards);
• IT Operation Controls;
• Physical Controls (access and environment);
• Logical Access Controls;
• Acquisition and Programme Change Controls; and
• Business Continuity and Disaster Recovery Controls.
Application Controls
Application controls pertain to specific computer applications. They include controls that
help to ensure the proper authorisation, completeness, accuracy and validity of transactions,
maintenance and other types of data input. Examples include system edit checks of the format of
entered data to help prevent possible invalid inputs, system enforced transaction controls that
prevent users from performing transactions that are not part of their normal duties and the
creation of detailed reports and transaction control totals that can be balanced by various units to
the source data to ensure all transactions have been posted completely and accurately.
Application controls are unique to an application and may have a direct impact on the
processing of individual transactions. These controls are used to provide assurance (primarily to
management) that all transactions are valid, complete, authorised and recorded.
Since application controls are closely related to individual transactions it is easier to see
why testing the controls will provide the auditor with audit assurance as to the accuracy of a
particular account balance. For example, testing the controls in a payroll application would
provide assurance as to the payroll figure in an auditee’s accounts. It would not be obvious that
testing the auditee’s general IT controls (e.g. change control procedures) would provide a similar
level of assurance for the same account balance.
As they are related to transaction streams application controls normally include:
• Controls over the input of transactions;
• Controls over processing;
• Controls over output; and
• Controls over standing data and master files.
Many application controls are simply computerised versions of manual
controls, e.g. computerised authorisation by a supervisor using an access code rather
that putting a signature on a piece of paper.
Specific Controls
Specific control issues that cover the following:
• Network and Internet controls including the risk associated with networks and
internet controls.
• End user computing controls including risks associated with end user computing and the
associated controls.
• e-Governance
• IT Security Policy
• Outsourcing Policy
Information System Development Audit
Information system development audit ensure control over the entire development process
from the initial idea or proposal to acceptance of a fully operational system are complied
satisfactorily.
While the IT Auditor may not be an IT developer, programmer or technician,
the auditor’s overall contribution generally is to ensure:
• Controls are identified and developed into the new system;
• Controls exist to manage the project and development project decisions are transparent;
• Predetermined standards are set (and followed);
• Development specifications make sense and are cost effective;
• That future technology improvements are considered;
• Systems are robust and reliable, secure from unwanted interference and
auditable; and
• The development objectives are clear and achievable.
Efficiency of systems is an important aspect of system capability that leads to effective
use of resources. A key is controlling system development to prevent cost overruns and systems
that do not perform as required.
PART 2 IT CONTROL AUDIT
SCOPE
The purpose of the IT Control Audit module of these Guidelines is to provide guidance and
procedures to IT Auditors for application in the areas of risks, controls and audit considerations
related to Information Systems. It also assists IT Auditors in the scope of issues that generally
should be considered in any review of computer related controls over the integrity,
confidentiality and availability of electronic data.

DEFINITION OF IT CONTROLS
The capabilities of computer systems have advanced rapidly over the past several decades.
In many organisations, the entire data has been computerised and all the information is available
only in digital media. In this changed scenario, auditors have to adapt their methodology to
changed circumstances. While the overall control objectives do not change in an IT
environment, their implementation does. The approach of auditors to evaluate internal
controls has to change accordingly.

IT Controls in a computer information system are all the manual and programmed
methods, policies and procedures that ensure the protection of the entity’s assets, the
accuracy and reliability of its records and the operational adherence to the management
standards

CONTROLS IN A COMPUTERISED ENVIRONMENT

In an IT environment, the control components found in manual systems must still exist.
However, the use of computers affects the implementation of these components in several
ways. Information Technology controls are used to mitigate the risks associated with
application systems and the IT environment and broadly classified into two categories.

Presence of controls in a computerised system is significant from the

audit point of view as these systems may allow duplication of input or
processing, conceal
or make invisible some of the processes and in some of the auditee organisations where
the computer systems are operated by third party service providers employing their own
standards and controls, making these systems vulnerable to remote and unauthorised acces.

IT Control Audit involves two types of testing – compliance and substantive testing.
Compliance testing determines if controls are being applied in the manner described in the
programme

documentation or as described by the auditee. In other words, a compliance test

determines if controls are being applied in a manner that “complies with”
management policies and procedures. Substantive audit “substantiates” the adequacy of
existing controls in protecting the organisation from fraudulent activity and encompasses
substantiating the reported results of processing transactions or activities. With the help
of CAATTs software, IT Auditor can plan for 100 per cent substantive testing of auditee’s data.

Controls play a more important role in IT environment than in the manual system.
Auditors rely on assessment of controls to do their audit. However, the controls have
changed in IT environment. So, as auditors we have to be aware of the impact of computer on
the controls. In an IT environment, there are new causes and sources of error, which bring new
risks to the entity.

General Controls
General Controls include controls over data centre operations, system software acquisition and
maintenance, access security and application system development and maintenance. They
create the environment in which the application systems and application controls operate16.
Examples include IT policies, standards and guidelines pertaining to IT security and
information protection, application software development and change controls, segregation
of duties, business continuity planning, IT project management, etc

General controls are concerned with the organisation’s IT infrastructure, including any IT
related policies, procedures and working practices. They are not specific to individual
transaction streams or particular accounting packages or financial applications. In most
instances the general controls elements of an IT review will concentrate on the
organisation’s IT department or similar function. The major categories of general controls that
an auditor should consider are

 Organisation And Management Controls

 IT Operation Controls
 Physical Controls
 Logical Access Controls
 IT Acquisition Controls
 Programme Change Controls
 Business Continuity and Disaster Recovery Controls

Application Controls

Application Controls pertain to specific computer applications. They include controls that help
to ensure the proper authorisation, completeness, accuracy and validity of transactions,
maintenance and other types of data input. Examples include system edit checks of the
format of entered data to help prevent possible invalid inputs, system enforced transaction
controls that prevent users from performing transactions that are not part of their normal
duties and the creation of detailed reports and transaction control totals that can be balanced by
various units to the source data to ensure all transactions have been posted completely and
accurately. Application controls include: Input, Processing, Output and Master/Standing Data
Files controls

Specific Controls

Specific Controls are peculiar to a particular environment and emphasis controls which are
related to issues such as: network and internet, end user computing, e-governance, IT
security and outsourcing
PRELIMINARY EVALUATION

Guidelines should encompass preliminary evaluation of the computer systems covering;

 How the computer function is organised

 Use of computer hardware and software
 Applications processed by the computer and their relative significanceto the organisation
and
 Methods and procedures laid down for implementation of new applicationsor revisions to
existing applications

In the course of preliminary evaluation, the auditor should ascertain the level of control
awareness in the auditee organisation and existence (or non-existence) of control standards. The
preliminary evaluation should inter alia identify potential key controls and any serious key
control weaknesses. For each control objective the auditor should state whether or not the
objective has been achieved; if not, he should assess the significance and risks involved due to
control deficiencies

The results of preliminary assessments provide the basis for determining the extent and type of
subsequent testing. If IT auditors obtain evidence at a later stage that specific control objectives
are ineffective, they may find it necessary to re- evaluate their earlier conclusions and
other planning decisions based on the preliminary assessment

During the preliminary assessment phase of IT auditing, the IT auditor may gain an understanding
of the entity’s operations and identifies the computer related operations that are significant to the
audit. This would also facilitate IT auditor in assessing inherent risk and control risk, making a
preliminary assessment on whether general IT controls are likely to be effective and identifying
the general controls that would require to be tested.

AUDIT OF GENERAL CONTROLS

The IT auditor will focus on general controls that normally pertain to an entity’s major
computer facilities and systems supporting a number of different IT applications, such as
major data processing installations or local area networks. If general controls are weak, they
severely diminish the reliability of controls associated with individual IT applications i.e.
Application controls

The manual identifies critical elements that are basic and essential for ensuring adequate controls
availability. The IT auditor may use the information for evaluating the practices adopted by
auditee’s organisation

Organisational and Management Controls

These are the high level controls adopted by management to ensure that the computer systems
function correctly and that they are satisfying business objectives. The aim of IT auditor will
be to determine whether the controls that the auditee organisation has put in place are
sufficient to ensure that the IT activities are adequately controlled. In carrying out an
assessment, IT auditor should cover the following areas

Control Objectives

IT Planning and Senior Management Involvement

 To ensure that in IT planning and implementation, there exists an active
involvement of Senior Level Management so that IT is given the proper recognition,
attention or resources it requires to meet business objectives. Also there exists a formal IT
organisation structure with all staff knowing their roles and responsibilities, preferably by
having written down and agreed job descriptions.

Formal Organisational Chart and Job Description

 To ensure that a formal IT organisation structure exists with all staff knowing their roles
and responsibilities supported by clearly define job descriptions
Personnel and Training Policies
 To ensure that organisation has controls and procedures in place to reduce the risk of
mistakes being made. This may be achieved through the adoption of appropriate
personnel policies and procedures
Documentation and Document Retention Policies
 To ensure documentation maintained up to date and documentation retention
policies should be in place in an organisation. When reviewing an
organisation’s system of internal control, the IT auditor can gain much of the information
required from client documentation
Internal Audit Involvement
 To ensure management has ultimate responsibility for ensuring that an adequate system
of internal controls is in place. Management puts policies and procedures in
place and gets assurance that the controls are in place and adequately reduce
identified risks by relying on the review work carried out by internal auditors
Legal and Regulatory Compliance
 To ensure compliance with the legal and regulatory requirements. This will vary
from one country to another. Legal and regulatory requirements may include data
protection and privacy legislation to protect personal data on individuals, computer
misuse legislation to make attempted computer hacking and unauthorised computer
access a criminal offence; copyright laws to prevent the theft of computer software
Segregation of Duties
To ensure segregation of duties is a proven way of ensuring that transactions are
properly authorised, recorded and that assets are safeguarded. Separation of duties occurs
when one person provides a check on the activities of another. It is also used to prevent one
person from carrying out an activity from start to finish without the involvement of another
person

Risk Areas
An IT auditor should be aware of the following critical elements
  Inadequate management involvement may lead to a direction-less IT function which, in
turn does not serve the business needs. This may give rise to problems with the financial
systems being unable to meet new reporting requirements (which may occur due a
change in national accounting standards, or a change in government requirements)
 Poor reporting structuresleading to inadequate decision making. This may affect the
organisation’s ability to deliver its services and may affect its future as a going concern
(one of the fundamental accounting principles)
 Inappropriate or no IT planning leading to business growth being constrained by a lack of
IT resources ; e.g. the manager reports to the chief executive that the system is unable
to cope with an increase in sales. Overloading a computer system may lead to
degradation or unavailability through communication bottle- necks or system crashes
 Ineffective staff who do not understand their jobs (either through inadequate
recruitment policies or a lack of staff training or supervision). This increases the risk of
staff making mistakes and errors
 Disgruntled staff being able to sabotage the system, for example when staff find out they
are going to be disciplined or make redundant
 Ineffective internal audit function which cannot satisfactorily review the
computer systems and associated controls
 Loss of the audit trail due to inadequate document retention policies (includes both paper
and magnetic, optical media); and
 Security policies not in place or not enforced, leading to security breaches, data loss,
fraud and errors

Management establishes and approves the policies. The policies are usually high level
statements of intent. The policies may feed into standards. Detailed procedures (and
controls) flow from the standards. It is important here that while reviewing an organisation’s
IT policies and standards, the auditor should bear in mind that each auditee organisation is
likely to be different and have different organisational and management requirements.
The auditor may assess whether the client’s organisational structure and the place of IT within
the structure is appropriate

Audit Procedures

IT Planning and Senior Management Involvement

The roles and responsibilities of senior management in relation to their systems should be
considered in audit. The auditor should review the high level controls exercised by senior
management. An important element in ensuring that projects achieve the desired results is
the involvement of senior management. Important considerations for auditor are whether a
relevant committee are established involving senior management in computerisation project of
the organization

This committee are involved in the formulation of Information Strategic Plan which should cover
the following aspect:

 Effective management of information technology is a business imperative and

 increasingly a source of competitive advantage. The rapid pace of technological changes
together with the declining unit costs, are providing organisations with increasing
potential for:
 Enhancing the value of existing products or services;
 Providing new products and services; and
 Introducing alternative delivery mechanisms
 To benefit from information technology requires: foresight to prepare for the changes;
planning to provide an economical and effective approach; as well as, effort and
commitment in making it happen
 İnformation technology planning provides a structured means of addressing the impact of
technologies, including emerging technologies, on an organisation. Through the planning
process, relevant technologies are identified and evaluated in the context of the broader
business goals and targets. Based on a comparative assessment of relevant technologies,
the direction for the organisationcan can be established
 The implementation of information technologies may be a complex, time consuming and
expensive process for organisations. Information technology planning provides a
framework to approach and schedule, wherever possible, necessary information technology
projects in an integrated manner. Through this process, performance milestones can be
agreed upon, scope of specific projects established, resources mobilised and constraints or
limitations identified. Without effective planning, the implementation of information
technologies may be misguided, haphazard, delayed and more expensive than justified

Personnel and Training

Staff employment policies should be adopted to ensure that appropriate staff are chosen. There
should also be policies and procedures to deal with the other end of the employment cycle, i.e.
termination (whether voluntary or compulsory). When emploting new members of IT staff,
the organisation would be expected to take account of:
 Background Checks: including taking up references (in some countries it may be possible
to check for criminal convictions);
 Confidentiality Agreements: these state that the employee will not reveal confidential
information to unauthorised third parties; and
 Codes of Conduct: including contractual relationships with relatives, the acceptance of
gifts, conflicts of interest etc.

Documentation and Document Retention Policies

The auditor may also need to examine client documentation to test check individual
transactions and account balances. The policy on documentation should state that all system
documentation should be kept up to date and that only the latest versions should be used. The
policy may also state that backup copies of documentation should be stored in a secure
off-site location

Ultimately, if the organisation does not retain sufficient, appropriate evidence the auditor would
have difficulty in being able to provide an unqualified audit opinion. The auditor should
consider two types of documentation according to the audit approach:
  Compliance Testing: the auditor would require evidence of controls in operation during the
accounting period. This evidence may consist of reconciliations, signatures, reviewed
audit logs etc.
 Substantive Testing: assurance may require the auditor to examine evidence relating to
individual transactions. The audit may need to be able to trace transactions from initiation
through to their summarisation in the accounts. Where transaction details are recorded in
computer systems they should be retained for audit inspection.

There may be other non audit requirements which require the organisation to retain transaction
documentation, e.g. specific requirements of legislations and regulations

Internal Audit Involvement

The external auditor may assess about the quality of internal audit’s work acceptable, in
terms of planning, supervision, review and documentation. The external auditor can view the
organisation’s internal audit function as part of the overall control structure (since they
prevent, detect and correct control weaknesses and errors)

The external auditor should consider whether the IT audit department has the staff necessary to
carry out competent reviews on the organisation’s computer systems.

Legal and Regulatory Compliance

It may be assessed whether the organisation is aware of local requirements and have taken
appropriate measures to ensure compliance

Segregation of Duties

Evidence of separation of duties can be obtained by obtaining copies of job descriptions,

organisation charts and observing the activities of IT staff. Where computer systems use
security profiles to enforce separation of duties, the auditor should review on-screen
displays or printouts of employees security profiles in relation to their functional
responsibilities

The ability to apply and enforce adequate separation of duties is largely dependent upon
the size of the IT department and the number of computer staff involved. Lack of
segregated duties in a small computer department can be addressed by compensating controls, e.g.
regular management checks and supervision, the use of audit trails and manual controls.
However, in a large computer department the following IT duties should be adequately
segregated:

 Systems design and programming

 Systems support
 Routine IT operations
 Data input
 System security
  Database administration
 Change management

In addition to segregated duties within the IT department, there should be no staff with dual IT
department and finance department duties. The computer department should be
physically and managerial separate from end users, such as finance and personnel.
Segregation of duties reduces the risk of fraud since collusion would be required to bypass the
control

IT Operation Controls
Control Objectives

The roles of IT operations include the following:

 Capacity Planning: i.e. ensuring that the computer systems will continue to provide a
satisfactory level of performance in the longer term. This will involve IT operation staff
having to make estimates of future CPU requirements, disk storage capacity and network
loads capacity
 Performance Monitoring: monitoring the day to day performance of the system in terms of
measures such as response time.
 Initial Program Loading: booting up the systems, or installing new software.
 Media Management: includes the control of disks and tapes, CD ROMS, etc
 Job Scheduling: a job is normally a process or sequence of batch processes which
are run overnight or in background and which update files etc. Jobs are normally run
periodically, either daily, weekly, monthly, quarterly or annually.
 Back-ups and Disaster Recovery: backups of data and software should be carried
out by IT operations staff on a regular basis.
 Help Desk and Problem Management: help desks are the day-to-day link between
users with IT problems and the IT department. They are the ones users call when they
have a printer problem or they forget their password. Problems may be encountered
with individual programmes (applications and system), hardware, or
telecommunications.
 Maintenance: both hardware and software.
 Network Monitoring and Administration: The IT operations function is given the
responsibility to ensure that communication links are maintained and provide users
with the approval level of network access.

Risks Areas
The risks associated with poorly controlled computer operations are:

 Wrong Applications Run, Incorrect Versions or Wrong Configuration Parameters: e.g. the
system clock and date being incorrect which could lead to erroneous interest charges,
payroll calculations etc
 Loss or Corruption of Financial Applications or the Underlying Data Files: may result
from improper or unauthorised use of system utilities. The IT operations staff may
 not know how to deal with processing problems or error reports. They may cause more
damage then they fix
 Delays and Disruptions in Processin: wrong priorities may be given to jobs
 Lack of Backups and Contingency Planning: increases the risk of being unable to continue
processing following a disaster
 Lack of System Capacity: the system may be unable to process transactions in a timely
manner because of overload, or lack of storage space preventing the posting of any new
transactions;
 High Amount of System Downtime to Fix Faults: when the systems are unavailable
a backlog of unposted transactions may build up
 Unresolved Users Problems: due to a poor help-desk function. Users may attempt to fix
their own problems

Audit Procedures

Service Level Agreements (SLA)

It is increasingly common for IT departments to draw up and agree service level

agreements with the rest of the organisation, i.e. the user departments. This allows users to
specify and agree, preferably in writing, what levels of service, in terms of quantity and
quality they should receive. SLAs are infect internal service delivery contracts.

A typical SLA would contain the following:

 General provisions (including the scope of the agreement, its signatories, date of next
review)
 Brief description of services (functions applications and major transaction types)
 Service hours (normal working hours and special occasions such as weekends and bank
holidays)
 Service availability (percentage availability, maximum number of service failures and
the maximum downtime per failure);
 User support levels (help desk details)
 Performance (response times, turnaround times )
 Contingency (brief details of plans);
 Security (including compliance with the organisation’s IT security policy)
 Restrictions (maximum number of transactions, users)

Management Control, Review and Supervision

Operations staff should be supervised by management. From the standpoint of separation of

duties, operations staff should not be given the job of inputting transactions or any form of
application programming.

The organisation’s IT systems may have on them software utilities which could
conceivably be used to make unauthorised amendments to data files. Operations staff
with access to such software should be supervised to ensure that they only use the utilities for
authorised purposes.

Management will be unable to provide continuous monitoring of operations staff and may place
some reliance on the automatic logging and monitoring facilities built into the systems. The
events which are recorded in the logs will depend on the parameters set when the systems were
installed. As with most logging systems, a large quantity of data can be produced in a short
period.
Effective supervision over IT operations staff is often difficult to achieve, due to their high level
of technical knowledge. They could do things to the system which management would not detect,
or even recognize the significance of, if they did detect a change. Therefore to a certain extent
management must place a high degree of trust on IT operations staff and that trust will be based
on appropriate staff selection and vetting procedures (as per the organisational and management
controls discussed in the previous topic.

Training and Experience

IT operations staff should have skills, experience and training necessary to carry out their
jobs to a competent standard. The IT auditor should determine if the training needs of IT
operations staff have been assessed. Training needs may include non-technical training, e.g.
management training for IT operations supervisors.

As an aid to continuity of staffing, some organisations may teach staff more than one role or
introduce a form of job rotation.

Computer Maintenance
As with most equipment, computers may require regular maintenance to reduce the risk of
unexpected hardware failures. Although preventive maintenance is becoming less common,
especially for mini and microcomputers, it may still be required for environmental
equipment such as air conditioning units and fire extinguishing systems.

The IT auditor may wish to examine the maintenance contracts and schedules
to determine if adequate maintenance is carried out. Ultimately the key test to the adequacy of
the organisation’s maintenance arrangements is the amount of system down-time or the
number of help-desk incidents arising from equipment failures.

Operations Documentation

The organisation should have clear, documented operating procedures for all computer systems to
ensure their correct, secure operation.The documented procedures should be available for
the detailed execution of each job and should include the following items:

 The correct handling of data files;

 Scheduling requirements (to ensure best use of IT resources);
 İnstructions for handling errors or other exceptional conditions which might arise when
jobs are run;
  Support contacts in the event of unexpected operational or technical difficulties;
 Special output handling instrauctions
 System restart recovery procedures.

The organisation should also have documented procedures for daily housekeeping and
maintenance activities such as computer start-up procedures, daily data back-up procedures,
computer room management and safety.

Documentation can be used by operations staff when they are unsure about how to carry out a
procedure. They are also useful in training new staff.

Problem Management

The IT operation section should have documented procedures for detecting and recording
abnormal conditions. A manual or computerised log may be used to record these conditions.

The ability to add an entry to the log should not be restricted; however the ability to update the
log should be restricted to authorised personnel. Management should have mechanisms in place
to ensure that the problem management mechanism is properly maintained and than outstanding
errors are being adequately addressed and resolved

Network Management and Control

A range of controls is required where an organisation uses computer networks. Network managers
should ensure that there are appropriate controls to secure data in networks and that the network is
adequately protected from unauthorised access. The controls may include:
 Separation of duties between operators and network administrators
 Establishment of responsibility for procedures and management of remote equipment;
 Monitoring of network availability and performance. There should be reports and utilities
to measure system response time and down time; and
 Establishment and monitoring of security controls specific to computer network

Physical Access Controls

Control Objectives
The objective of Physical Controls is to prevent unauthorised access and interference to IT
services. In meeting this objective, computer equipment and the information they contain and
control should be protected from unauthorised users. They should also be protected from
environmental damage, caused by fire, water (either actual water or excess humidity),
earthquakes, electrical power surges or power shortages. In IT arena, the second most likely
cause of errors is natural disasters. The entity’s IT security policy should include consideration
of physical and environmental risks.

Risks Areas
Physical

 Accidental or intentional damage by staff

 Theft of computers or their individual components
 Power spikes or surges which may cause component damage and the loss or corruption of
data
 Bypass of logical access controls: e.g. having physical access to a fileserver can be
exploited to bypass logical controls such as passwords
 Copying or viewing of sensitive or confidential information, e.g. pre-published results and
government policies

Environmental

 Fire /water damage (or damage from other natural disasters);

 Power: Cuts, leading to loss of data in volatile storage (RAM)
 Spikes: leading to system failures, processing errors, damage to components of equipment
 Failure of equipment due to temperature or humidity extremes (or just outside tolerances of
a few degrees);
 Static electricity: can damage delicate electrical components. Computer chips (ROM,
RAM and processor) are delicate and easily damaged by static electricity shocks
 Others: e.g.

Audit Procedures

To ensure that adequate internal controls exist to protect the business’s assets and resources, the
organisation should carry out a risk assessment.This would involve identifying the threats to
the systems, the vulnerability of system components and likely impact of an incident occurring.
Then he should identify counter-measures to reduce the level of exposure to an acceptable level.
To do this, he must balance the risks identified with the cost of implementing controls.

Physical Controls

 Physical access controls are specifically aimed at ensuring that only those who have been
authorised by management have physical access to the computer systems. Physical
access security should be based upon the concept of designated perimeters which
surround the IT facilities
 Physical access controls reduce the risk of unauthorised persons gaining access to the
computer equipment. The auditor should identify controls which would restrict access to
the organisation’s site, the computer rooms, terminals, printers and data storage media
 Access to the organisation’s site and secure areas should be controlled by layers of
controls, starting at the perimeter fence and working in through the building’s entrance to
the computer suite and terminals.
Environmental Controls

 Computer Computer installations should be protected against hazards such as fire, flood,
power cuts, physical damage and theft. Inadequate protection increases the risk to system
availability and ultimately an organisation’s ability to produce a complete record of
financial transactions. The organisation should have assessed the exposure to damage
and introduced appropriate controls to reduce the risk to an acceptable level.
 The risk of fire damage can be reduced by the provision of fire detection and fire fighting
equipment. Other measures, such as regular cleaning and removal of waste from the
computer room, will reduce the risk of fire damage.
 The risk of water damage is largely dependent on the location of the computer facilities.
Equipment located in close proximity to pipes and water tanks are at increased risk.
Where possible, organisations should avoid locating computer equipment in basements
or on floors immediately below or in the vicinity of water tanks. Automatic
moisture detectors may be used to alert IT staff of potential water ingress.
 Computer equipment may be damaged or disrupted by fluctuations in the electrical
power supply. Power surges can cause computer systems to delete or contaminate data.
Uninterruptible power supplies reduce the risk of system disruption and damage and
can allow continued processing following a power cut.

Logical Access Controls

Logical Access Controls are defined as: “a system of measures and procedures, both
within an organisation and in the software products used, aimed at protecting computer resources
(data, programmes and terminals) against unauthorised access attempts.

Control Objectives

The objective of logical access controls is to protect the financial applications and underlying
data files from unauthorised access, amendment or deletion. The objectives of limiting access
are to ensure that:
 Users have only the access needed to perform their duties
 Access to very sensitive resources such as security software program, is limited to very few
individuals and
 Employees are restricted from performing incompatible functions or functions beyond their
responsibility

Risk Areas
 Users have the access to the areas other than related to the performance of their duties,
causing threats to unauthorised access, amendment or deletion in the maintained
data.
 Access to very sensitive resources such as security software program which may be of the
mission critical nature and
 Employees are not barred from performing incompatible functions or functions beyond
 their responsibility

Audit Procedures

Logical access controls can exist at both an installation and application level. Controls within the
general IT environment restrict access to the operating system, system resources and applications,
whilst the application level controls restrict user activities within individual applications.

The importance of logical access controls is increased where physical access controls are less
effective, for example, when computer systems make use of communication networks
(LANs and WANs). The existence of adequate logical access security is particularly important
where an organisation makes use of wide area networks and global facilities such as the Internet.

Logical access controls usually depend on the in-built security facilities available under the
operating system (e.g. NOVELL Network) or hardware in use. Additional access controls can be
gained through the appropriate use of proprietary security programs.

The most common form of logical access control is login identifiers (ids) followed by
password authentication. For passwords to be effective there must be appropriate password
policies and procedures, which are known to all staff and adhered to.

Menu restrictions can be effective in controlling access to applications and system utilities.
Systems may be able to control access by identifying each individual user through their unique
login ids and then having a pre-defined profile of authorised menus for each.

Some computer systems may be able to control user access to applications and data files by
using file permissions. These ensure that only those users with the appropriate access
rights can read, write, delete or execute files.

Significant risks are often posed by system administration staff with powerful system privileges.
These ‘super users’ may have access to powerful system utilities that can by-pass established
system controls. Management should have introduced measures to control the activities of these
powerful users and, if possible, limit the system privileges of individual administrator to those
required by their function.

The critical elements of an access control mechanism should include:

 Classification of information resources according to their criticality and sensitivity
 Maintenance of a current list of authorised users and their access privileges
 Monitoring access, investigating apparent security violations and take appropriate
remedial action.

IT Acquisition Controls
The importance of IT related acquisitions is usually directly proportional to their cost, scale
and complexity. In general, the larger and more complex the acquisition, the
higher will be its impact on and importance to, the business. In addition, the acquisition
may be important to the business due to its interrelationships with other IT projects.

Control Objectives

A structured acquisition process provides a framework for ensuring that:

 There are no major omissions from a business, technical or legal standpoint;
 The costs and resources for the acquisition process are appropriate and are efficiently
deployed
 The validity of the business case in support of the acquisition is reaffirmed prior to
selecting a solution; and
 There is progressive buy-in to the new system as a result of user group involvement
throughout the acquisition process

Programme Change Controls

After systems are implemented the system maintenance phase begins. Systems rarely
remain the same for long. Even on the day systems go live there are invariably users who are not
satisfied with the systems and submit request for changes
to be made.

Changes may be requested for the following reasons:

 Functionality Enhancement: everyday system users may not be content with the
functionality of the system. This could include discontentment with the screens they have,
the system response time;
 To Make Systems Operations Easier, More Efficient: this category includes the tape/disk
operators, the helpdesk manager, the database administrator and network management
personnel
 Capacity Planning: the system may require additional resources or increased capacity
components.
 Problems Rectification: help-desk incidents leading to the identification of problems:
each incident recorded on the Helpdesk will contribute to the identification of
underlying problems. If the problems are significant enough a request for change may be
produced by the Helpdesk function
 To Improve Security: IT security personnel : identified weaknesses in system security may
result in requests for change which should improve security
 Routine Updates: system developers may update and improve the system software
 Changes in Requirements: changes in legislation, business requirements or business
direction may require the financial system to be amended.
Control Objectives

Even when the system development process has been completed and the new system is accepted, it
is likely that it will have to be changed, maintained, or altered during its lifecycle. This change
process may have an impact on the existing controls and may affect the underlying functionality of
the system. If the auditor intends to rely on the system to any extent to provide audit evidence, a
review of the change controls is required. Change controls are needed to gain assurance that the
systems continue to do what they are supposed to do and the controls continue to operate as
intended.

Change refers to changes to both hardware and software. Hardware includes the computers,
peripherals and networks. Software includes both the system software (operating system and any
utilities) and individual applications.

The scale of change can vary considerably, from adjusting a system’s internal clock, to installing a
new release of an application or operating system. The effect that a change has on the operation
of the system may be out of proportion to the size
or scale of the change made.

Risks Areas

Change controls are put in place to ensure that all changes to systems configurations are
authorised, tested, documented, controlled, the systems operate as intended and that there is an
adequate audit trail of changes.

Conversely the risks associated with inadequate change controls are:

 Unauthorised Changes: accidental or deliberate but unauthorised changes to the systems.
For example, if there are inadequate controls application programmers could make
unauthorised amendments to programs in the live environment;
 Implementation Problems: for example where the change is not in time for business
requirements, e.g. annual tax rates;
 Erroneus Processing and Reporting: systems which do not process as intended. This could
lead to erroneous payments, misleading reports, mis- postings of transactions and
ultimately qualified accounts;
 Use of Unauthorised Hardware and Software: systems (hardware and software) in use
which are not authorised. This could lead to incompatibility between different parts of the
system, or breach of copyright legislation

Audit Procedures

It may be ensured in audit that the organisation’s procedures to control changes should
include;
 Procedures for management authorisation;
 Thorough testing before amended software is used in the live environment
 The amended software is transferred or “transported” to the live environment only by or
 often authorised by operations management;
 Management review of the effects of any changes
 Maintanence of adequate records;
 The preparation of fallback plans (just in case anything goes wrong); and
 The establishment of procedures for making emergency changes

Business Continuity and Disaster Recovery Controls

Control Objective

The objective of having a Business Continuity and Disaster Recovery Plan and associated controls
is to ensure that the organisation can still accomplish its mission and it would not loose the
capability to process, retrieve and protect information maintained in the event of an
interruption or disaster leading to temporary or permanent loss of computer facilities.

Risks Areas

The absence or existence of a well defined and tested Business Continuity and Disaster Recovery
Plan may pose the following major threats to the very existence of the organisation itself in the
event of a Disaster:

 The organisation’s ability to accomplish its mission after re-starting its

operations.
 To retrieve and protect the information maintained
 To keep intact all the organisational activities after the disaster.
 To start its operations on full scale at the earliest to minimise the business loss in terms of
money, goodwill, human resources and capital assets.

Audit Procedures

The organisation with computerised systems should have assessed threats to the system, its
vulnerability and the impact a loss of operations would have on the organisation’s ability to
operate and achieve organisational objectives. Appropriate measures should then be put in place
to reduce risks to a level that is acceptable to the organisation’s senior management.

Continuity and Disaster recovery plans should be documented, periodically tested and
updated as necessary.

Back-up copies of systems software, financial applications and underlying data files should
be taken regularly. Back-ups should be cycled through a number of generations by, for example,
using daily, weekly, monthly and quarterly tapes. Back- ups should be stored, together with a copy
of the disaster recovery plan and systems documentation, in an off-site fire-safe.

AUDIT OF APPLICATION CONTROLS

Application controls are specific to an application and may have a direct impact on the
processing of individual transactions. These controls are used to provide assurance that all
transactions are valid, authorised, recorded, and complete. Since application controls are closely
related to individual transactions it is easier to see why testing the controls will provide the auditor
with audit assurance as to the accuracy of a particular account balance.

Before getting on to audit of application controls, it will be necessary for an auditor to secure a
reasonable understanding of the system. For this purpose, a brief description of the application
should be prepared;

 Indicating the major transactions,

 Describing the transaction flow and main output,
 Indicating the major data files maintained, and
 Providing approximate figures for transaction volumes.

Application Control requirements may be divided into:

 Input control
 Processing control
 Output control
 Master/ Standing Data File control

Input Controls

Control Objective

The objective of Input Control is to ensure that the procedures and controls reasonably guarantee
that (i) the data received for processing are genuine, complete, not previously processed, accurate
and properly authorised, and (ii) data are entered accurately and without duplication. Input control
is extremely important as the most important source of error or fraud in computerised systems is
incorrect or fraudulent input. Controls over input are vital to the integrity of the system.

Risk Areas

Weak input control may increase the risk of:

 Entry of the unauthorised data

 Data entered in to the application may be irrelevant.
 Incomplete data entry
 Entry of duplicate/redundant data.
Audit Procedures

The aspects that the auditor should evaluate are:

 All prime input, including changes to standing data, is appropriately authorised.
 For on-line systems, the ability to enter data from a terminal is adequately
restricted and controlled.
 İf there is a method to prevent and detect duplicate processing of a source
document,
 All authorised input has been submitted or, in an on-line system transmitted and there are
procedures for ensuring correction and resubmission of rejected data

Processing Controls

2.124 Processing Controls ensure complete and accurate processing of input and generated
data. This objective is achieved by providing controls for:
 Adequately validating input and generated data,
 Processing correct files ,
 Detecting and rejecting errors during processing and referring them back to the originators
for re-processing,
 Proper transfer of data from one processing stage to another and
 Checking control totals (established prior to processing) during or after processing.

Control Objectives

The objectives for processing controls are to ensure that:

 Transactions processing is accurate;
 Transactions processing is complete;
 Transactions are unique (i.e. no duplicates);
 All transactions are valid; and
 The computer processes are auditable

Risk Areas

Weak process controls would lead to:

 İnaccurate processing of transactions leading to wrong outputs/results.
 Some of the transactions being process by the application may remain incomplete.
 Allowing for duplicate entries or processing which may lead to duplicate payment in case
of payment to vendors for goods.
 Unauthorised changes or amendments to the existing data.
 Absence of audit trail rendering sometimes the application unauditable.

Audit Procedures
The auditor should ensure that there are controls to detect the incomplete or inaccurate processing
of input data.

Application processes may perform further validation of transactions by checking data for
duplication and consistency with other information held by other parts of the system.

Computerised systems should maintain a log of the transactions processed. The transaction
log should contain sufficient information to identify the source of each transaction.

Output Controls

These controls are incorporated to ensure that computer output is complete, accurate and correctly
distributed. It may be noted that weakness in processing may sometimes be compensated by
strong controls over output. A well-controlled system for input and processing is likely to be
completely undermined if output is uncontrolled. Reconciliation carried out at the end of the
output stage can provide very considerable assurance over the completeness and accuracy of
earlier stages in the complete cycle.

Control Objectives

Output controls ensure that all output is:

 Produced and distributed on time,
 Fully reconciled with pre input control parameters,
 Physically controlled at all items, depending on the confidentiality of the document and
 Errors and exceptions are properly investigated and acted upon

Risk Areas

If output controls prevailing in the application are weak or are not appropriately
designed these may lead to:
 Repeated errors in the output generated leading to loss of revenue, loss of creditability of
the system as well as that of the organisation.
 Non- availability of the data at the time when it is desired.
 Availability of the data to an unauthorised person/user.
 Even sometimes, the information which may be of very confidential nature may go to the
wrong hands.

Audit Procedures
The completeness and integrity of output reports depends on restricting the ability to amend
outputs and incorporating completeness checks such as page numbers and check sums.

Computer output should be regular and scheduled. Users are more likely to detect missing output
if they expect to receive it on a regular basis.
Output files should be protected to reduce the risk of unauthorised amendment.

Master/Standing Data File Controls

Control Objective

Master/Standing Data File Controls are meant for integrity and accuracy of master and
standing data files.

Risk Areas

Accuracy of data on master and standing files is of vital importance, to the auditor. Information
stored in master and standing data files is usually critical to the processing and reporting of
financial data. Weak control in the system in maintenance of master/standing data files may lead
to:
 Unauthorised and uncontrolled amendments to the master and standing data files.
 Unrestricted and uncontrolled physical and logical access to the application data files.
 Poor documentation of the amendment procedures etc.

Audit Procedures

Auditors should see the following while examining the system:

 Amendments to standing data are properly authorised and controlled.
 İntegrity of master and standing data files is verified by checking, control totals and
periodic reconciliation with independently held records.
 Amendment procedures are properly documented and controlled by management
authorisation and subsequent review and
 Physical and logical access to application data files are restricted and controlled.

AUDIT OF SPECIFIC CONTROLS

This section would focus on these specific controls that cover the following:
 Network control and use of the Internet including the risk associated with networks and
network controls.
 End user computing controls including risks associated with end user computing and the
associated controls.
 E- Governance
 IT Security Policy
 Outsourcing
PART 3 INFORMATION SYSTEM DEVELOPMENT AUDIT

AUDIT OBJECTIVES
The audit objectives for both the Ongoing Project Audit and the Post Implementation
Audit is the same.
The objective of the audit is to ensure that the development process is in compliance with
the prevailing policies and regulations; the overall project management and controls over
development of the system are satisfactory, pertinent and sufficient internal control and audit
trails are in place; the quality of the system development is maintained and the system ultimately
support the strategic objective of the organisation as well as meeting the needs of the users.
PROJECT MANAGEMENT
A sound project management adopted during system development on IT based
system will determine the success of failure of the project.
Auditor will examine the effectiveness of the project management methodology adopted
by the organisation in executing this project plan. Among the component to be evaluated are:
project organisation, the nature and extent of responsibilities, authority and accountability of the
project management, empowerment of the various parties, the effectiveness of the team leader
and the usage of resources.
RISK MANAGEMENT
The overall objective of the audit in system development is to contribute to the success of
the system project. To ensure that the system under development will achieve a satisfactory
conclusion, the organisation should focus on risk management of the project. Four phases of risk
management of project as follow:
• Assessment Phase: Organisation evaluates their security risks by determining their assets,
threats, and vulnerabilities.
• Planning Phase: Established security policies to define threats (tolerable and intolerable threat).
A threat is tolerable if the cost of safeguard is too high or the risk is low. The policies also specify
the general measures to be taken against those that are intolerable or a high priority.
• Implementation Phase: Specific technologies are chosen to counter highpriority threats. The
selection of particular technologies is based on the general guidelines established in the planning
phase.
• Monitoring Phase: A continuous process used to determine whether measures are successful or
not and need modification; there are any new types of threats; there have been advances or
changes in technology; and whether there are any new business requirements with potential risk
exposure.
Basically the auditors role is to identify the risk exposure and evaluate the operability,
completeness and sufficiency of the risk management plan establish by the organisation. The two
types of risk exposures in system development are:
• Security risk exposure stem from inadequate built-in automated control designed to validate
data processing; to restrict access to data, ensure a sound separation of roles and to monitor
system usage; and to provide appropriate business continuity
• Project risk exposure relates to the financial justification for the project, and includes such
impact as late delivery, cost over-runs, failure to deliver the anticipated business benefits and
premature obsolescence.
Appendix 3.1 summarised the risk exposures breakdown into a number of detail risk.
Listed below are factors which are essential ingredients for successful
project management:
• There must be clear and concise statement of what the project is setting out to achieve and this
must be understood and accepted by all the stakeholders.
• It is essential to identify who the eventual customer of the project’s deliverables is. The
customer is the main beneficiary of the project and will have an important role in agreeing with
the project goal and providing essential support.
• An effective change management system is essential to safeguard projects from uncontrolled
changes.
• For successful project management an effective project organization should be created with
proper definition of roles, responsibilities and reporting lines.
• A properly used project management methodology will promote the successful establishment,
operation and closure of a project.
• All risks associated with projects should be identified and appropriately managed.
• Since projects very often form business relationships between groups of people who normally
do not work with each other, appropriate team building measures should be adopted. Openness
and honesty should be encouraged so that problems are not disguised.
• Projects involve movement from one system to another and hence a clear transition strategy is
essential to a project’s success.
• It is essential to have an experienced project manager with sufficient status in the organisation.
FUNDING
All system development should be subjected to budgetary controls to ensure resources are
adequately allocated and to allow for benchmarking to be made for progress and cost of project
against funding. Therefore, accurate estimates of timescales and resources are essential
ingredients of any realistic plan. Ideally all project stakeholders should be involved in either
preparing or reviewing estimates/funding. Those involved in the preparation of estimates must be
given authority and backing to obtain the information required about the project needed to
perform the estimating task. They should:
• become familiar with the proposed system;
• be aware of the environment in which the proposed system is to be produced/developed;
• prepare the estimate, using the appropriate estimating models and techniques
• assess the effects that factors in the local development environment may have on the estimates;
• advise the Project Manager how to interpret the estimate, including the various risks;
• re-estimate as the project proceeds and when more accurate estimates are possible
The audit review will include the use of realistic estimate to complete tasks and the
effectiveness of the project team and the usage of resources.
DELIVERABLES
It is important to ensure that a team is working on the most appropriate tasks by building a
detailed schedule and sticking to it to ensure that the project will complete on time. Auditor
should assess the milestone achieved against the implementation schedule to ensure promptness
and consistency of time reporting and the completion of task and deliverables.
Listed below are the Project Scheduling Principles that could be considered in defining
the deliverables during the system development:
• Compartmentalisation: The product and process must be decomposed into a manageable
number of activities and tasks.
• Interdependency: Tasks that can be completed in parallel must be separated from those that
must be completed serially.
• Time Allocation: Every task has start and completion dates that take the task interdependencies
into account.
• Effort Validation: Project manager must ensure that on any given day there is enough staff
members assigned to complete the tasks within the time estimated in the project plan.
• Defined Responsibilities: Every scheduled task needs to be assigned to a specific team member.
• Defined Outcomes: Every task in the schedule needs to have a defined outcome (usually a work
product or deliverable).
• Defined Milestones: A milestone is accomplished when one or more work products from an
engineering task have passed quality review.
In a phased methodology of system development each phase represents a milestone on
that certain objectives should have been met, decisions made, data gathered or analysed.
ADHERENCE TO STANDARDS
The auditor should ensure that deliverables at each phases of the implementation is clearly
defined in advance so that it could be easily evaluated in terms of quality assurance, timeliness,
relevancy and completeness, and more importantly as a benchmark against which project can be
measured.
SDLC standards provide procedural controls over development of new system. It will
involve a series of stages throughout the development process where an authorisation is required
at each stage along with a review of progress.
Auditors could assess the consistency of practices and standard employed with
regard to the various phases of the system development system analysis and specification,
system design, system development, acceptance testing, implementation and post implementation
review. Figure 1 below shows the life cycle responsibilities of the various groups and their
deliverables.
SYSTEM DEVELOPMENT METHODOLOGY
The auditee’s organization should adopt a methodology to ensure that systems are
implemented using technique designed to provide effective systems without taking unacceptable
risks that would jeopardize the auditee’s operations.
It is important for the auditor undertaking this audit to be aware of the various types of
development methodology that could be adopted by the auditee’s organisation. That being the
case, auditor should be familiar with the controls and standard over the development process
based on the methodology adopted by the auditee’s organisation.
The most established and standard methodology known as the System Development Life
Cycle (SLDC) involves common activities describe below:
• Performing the feasibility study;
• Identifying users’ requirement;
• Identifying and evaluating alternatives;
• Transforming user requirement into system specifications;
• Preparing the system design for development;
• Conducting the various types of testing – such as unit, integration and eventually acceptance
testing;
• Rectifying problem encountered;
• Preparing the various types of documentation - such as end user and system documentation;
• Implementing the new system for life operation; and
• Performing the post implementation review (PIR) where feedback will serve as input for the
system maintenance
Initiation Phase
During the Initiation Phase, the justification for the need for an IT based solution to a
problem is identified, quantified and confirmed.
The organisation should prepare a clear, convincing, well supported by evidence and fact
based business case. This document will help to convince the relevant authority that the project
will bring real benefit to the organisation before endorsing it. A standard business should include
the following:
• why the system is needed;
• the business objectives to be met or enhanced;
• any long term business implication;
• any staff and organisation implication;
• the alternative options which were considered;
• the recommended option;
• any important assumptions that have influenced recommendation;
• when the system can be delivered;
• its overall priority among other impending projects;
• the benefits to be delivered by the system;
• the risk of not delivering the benefits;
• the risks involved in pursuing the project;
• an investment appraisal;
• outline cost and plans for the project
The objective of the initiation stage is to underline the groundwork for future management
of a project and to obtain approval for its commencement. Initiation might relate to a study to the
entire project, or to a single stage of a project. Therefore initiation stage might occur at a number
of stages in the system development. The following areas need to be addressed during the
initiation stage:
• the scope of the project;
• appointment of project team and quality assurance team;
• appointment of staff and consultancy support;
• training needs before project commences;
• any options raised in earlier report (Project Initiation Report)
• continuing validity of the existing user requirements, and any assumptions and
recommendations;
• the identification and management of both business and security risk
In conducting the audit review for the Initiation Phase, the auditor will have to
communicate directly with the project team. He/she well identify those deliverables that have
direct impact to either proceed or discontinue the project. These deliverables should be evaluated
rigorously to allow the auditor to form an opinion on the reasonableness of the decision taken
related to the system. The prominent deliverables at the Initiation Phase are:
• The Needs Statement which include an expression of the need in terms of an organisation
strategic plan, problem areas, reforms or process re-engineering proposed and alternatives,
opportunities in improving economy and efficiency, the internal control and security needed for
the system.
• The Feasibility Study which include an analysis of objectives, requirements, and system
concepts, an evaluation of alternative approaches and a description of the proposed approach.
• The Risk Analysis which include the identification of internal control and security
vulnerabilities, the nature, magnitude and safeguards of associated threats and assets covered by
the proposed system, and a detailed review of all data and assets to be processed or accessed by
the system.
• The Cost/Benefit Analysis which include the cost to build the system, system benefits, impact to
system internal control and security etc.
System Analysis
The real start of any development project is the system analysis phase or also known as
Definition of Functional Requirements. The activities involve in this phase include
interviewing users, reviewing existing documentation, defining data, and modelling the data and
processes that define the functionality of the system.
To avoid system inefficiency and delivery delays, it is important that the users
requirements are fully captured and understood in order to avoid changes and/or new
requirements emerging at later stages.
During the system analysis phase, the auditors will evaluate whether end users needs are
well defined and transformed into requirement definitions. Basically, the deliverables at this
phase are:
• The user requirement statement which capture the needs from the various users.
• The Functional Requirements Document which includes the detailed information on the system
input screen layout, coding the automated process, interfaces, output format and the controls and
the security requirements.
• The Data Requirement Document which defines the detailed description of the data require as
input and output, data logical groupings, characteristics of each data element, the procedures for
data collection, and description for sensitive and critical data.
System Design
In design and development phase, the logical data and process models which were created
during the analysis process are used to create the physical design of the system. This phase is
concerned with how the functional requirements will actually be provided and provides a
definition for the programmers who will go on to build the system.
System Development
Once the program and database specifications are completed, they must be translated into
the commands and instructions required by the computer to run the system. There are a variety of
ways in which this can be done ranging from the traditional writing of a string of program
instructions to newer techniques which include Rapid Application Development (RAD), Case
Tools and Object Orientation Programming.
The development phase also includes the testing which must be carried out to ensure that
the system is operating as required by the functional requirements. Various levels of testing will
be carried out including:
• Unit testing: to ensure individual program modules function correctly.
• Integration testing: to ensure that related program modules work together.
• System testing: to ensure that the whole system works as required.
• Acceptance testing: the final test by the users to ensure that the system actually does what they
wanted in the first place.
The deliverables developed at the end of this phase are:
• User manual which describe the functionality of the system in non-technical terminology.
• Operating manual provide IT staff with a description of the system and the operational
environment.
• Maintenance manual provides technical staff with the information and source codes necessary
to understand the program, their operating environment, their maintenance procedures and
security requirements.
• The verification and testing plan which includes all testings done supported by the test results.
• Migration Plan describes the installation or implementation of the system for system roll-out.
This document is used after testing of system, including security and internal control features
have been carried out.
The auditor should evaluate the adequacy of the documentation, the coding and their
testing efforts carried out.
Implementation and Maintenance
This phase involves the migration from existing system to new system. This will take
place after the users are satisfied that the system has undergone successful testings and the
auditee’s organization has signed off.
It is during this stage where the actual operation of the system in a production
environment is seen. Problems/issues related to violations of system security, backup plan,
business continuity plan, standing data file integrity and other programmes malfunctions will be
taken up for maintenance.
The deliverables developed at the end of this phase are:
• Migration Plan which will elaborate of the cutover method adopted and the controls over data
transferred to new system;
• Report on problems which require maintenance; and
• Corrective measures to tackle the problems identified earlier supported by the appropriate
documents.
Post Implementation Review
A Post Implementation Review (PIR) is the final stage of a system development project.
Its aim is to establish the degree of success achieved by the development project and to determine
whether any inputs can be applied to improving the organisation’s development process. The full
scope of a PIR will depend largely on the scale and complexity of the project. Overall it should
establish in an impartial manner whether a new system has met its:
• business objectives (delivered within budget and deadline; is producing predicted savings and
benefits, etc.)
• user expectations (user friendly, carries the workload, produces the required outputs, good
response time, reliable, good ergonomics, etc.);
• technical requirements (capable of expansion, easy to operate and maintain, interfaces with
other systems, low running cost, etc.).
During the PIR it is also important to identify any lessons which can be used to improve
the organisation’s development process. In order to facilitate control, the PIR should have terms
of reference, authorised by the approving authority, defining the
• scope and objectives of the review;
• criteria to be employed in measuring the achievement of objectives;
• management and organisation of the review team;
• review budget and reporting deadline
The auditor should evaluate the PIR report to determine the adequacy of
efforts in assessing the system.
(Appendix 3.2 is a sample Audit Programme that could be considered to perform the
System Development Audit)
PART 4 COMPUTER ASSISTED AUDIT TECHNIQUES AND TOOLS (CAATTs)
INTRODUCTION
Computer Assisted Audit Techniques And Tools (CAATTs), are computerbased tools and
techniques which permit auditors to increase their productivity as well that of the audit function
in gathering audit evidence by exploiting the power and speed of computer. CAATTs have the
ability to improve the range and quality of audit and fraud investigation results. It has nowadays
become an integral part of the whole audit work.
CAATTs may also provide effective tests of control and substantive procedures where
there are no input documents or a visible audit trail, or where population and sample sizes are
very large. This is done by making use of the wide range of techniques and tools to automate the
test procedures for evaluating controls, obtaining evidence and data analysis. The auditor can use
CAATTs as an integral part of the whole audit work to gather audit evidence independently.
CAATTs provide a means to gain access and to analyze data for a predetermined audit objective
and to report the audit findings with emphasis on the reliability of the records produced and
maintained in the system.
OBJECTIVES
The overall objectives and scope of an audit do not change when an audit is conducted in
an Information Technology environment. The application of auditing procedures may, however,
require the auditor to consider techniques known as Computer Assisted Audit Techniques
(CAATTs) that use the computer as an audit tool.
CAATTs may be used in performing various auditing procedures and improving the
effectiveness and efficiency of obtaining and evaluating audit evidence. CAATTs are often an
efficient means of testing a large number of transactions or controls over large population by:
• analysing and selecting samples from a large volume of transaction,
• applying analytical procedures, and
• performing substantive procedures.
CAATTs make remote and continuous auditing possible. By installing file interrogation
tools at remote locations, auditors could continuously monitor activities and report any
exceptions to the home office.
CAATTs may be used in performing various auditing procedures, including the following:
• tests of details of transactions and balances, for example, the use of audit software for
recalculating interest or the extraction of invoices over a certain value from computer records.
• analytical review procedures, for example, to identify inconsistencies or significant fluctuations.
• use of expert system, for example, in the design of audit programs and in audit planning and
risk assessment.
• tests of general controls, for example, to test the set up of configuration of the operating system
or access procedures to the program libraries.
• sampling programs to extract data for audit testing.
• tests of application controls, for example, to test the function of programmed control.
• creation of electronic working papers, for example, by downloading the general ledger for audit
testing.
• recommitting calculations performed by the entity’s accounting systems.
MAJOR STEPS IN USING CAATTs
The major steps to be undertaken by the auditor in the usage of CAATTs are
to:
• set the objectives of the CAATTs application;
• determine the content and accessibility of the entity’s files and data,
• identify the specific files or databases to be examined;
• understand the relationship between the data tables where a database is to be examined;
• define the specific tests or procedures and related transactions and balances affected;
• define the output requirements;
• arrangement with the user and IT departments, if appropriate, for copies of the relevant files or
database tables to be made with the appropriate cut off data as per the period of audit and time;
• identify the personnel who may participate in the design and application of the CAATTs;
• refine the estimates of costs and benefits;
• ensure that the use of the CAATTs is properly controlled and documented;
• arrange the administrative activities, including the necessary skills and computer facilities;
• reconcile data to be used for the CAATTs with the accounting records.
• execute the CAATTs application;
• evaluate the results.
TYPES OF CAATTS
CAATTs can be split into two discreet areas of operation namely to validate
programmes/systems (functionality of the programmable controls) and to analyse data files.
Discussed below are some CAATTs that fall in this category.
CAATTs Used to Validate Programmes/Systems
Program Code Review
Program review involves a detailed examination of programme coding. It generally
involves a fair degree of programming skill and a thorough knowledge of programme
specification. By reading programme source codes, auditors should identify any of the following:
• Identify Erroneous Code: The use of code review to identify erroneous code is well established.
Thus auditors can use code review to determine whether program code complies with its
specifications.
• Identify Unauthorised Code: Without directly examining a program’s source code, auditors are
unlikely to identify unauthorised code in a program. Unauthorised code often is triggered by a
specific data value or combination od data values. For example, a fraudulent programmer might
modify a program so it does not print out details of his or her own account when it is overdrawn.
Similarly, he or she might modify a program to execlude transactions having certain account
number and data values from normal data validation process. Unless auditors submit test data
having these specific values and have a way of checking that the test data has travversed all
execution paths in the code that is their focus, they are unlikely to detect this unauthorized code.
• Identify Ineffective Code: Auditors can examine whether code is ineffictive in two ways. First,
they can evaluate whether the code meets the documented program specifications. Second, they
can examine wether the code meets user reqirements. Moreover, assuming the program
specifications are corect, design errors that results in the program not complying with
specification are also prevalent.
• Identify Inefficient Code: Code review also can allow auditors to identify inefficient segments
of code. For example, in a sequence of tests of transaction types, the tests might not have been
ordered according to their frequency of occurrence. As a resulit, the program executes more of its
code than it would have to if the tests were recorded. Auditors might also use code review to
identify the existance of the instructions that execute inefficiently on the hardware/software
platform used.
• Identify Non-Standard Code: Non-standard code takes a variety of forms. For example, it could
be code that does not comply with organisational standards covering data item names or internal
dicumentation. Alternatively, it could be code that does not employ structured programmming
control structures. Whatever the nature of the nonstandard code, often it manifests other defects
in the code – for example, unauthorised code or erroneous code.
CAATTs Used to Analyse Data Files
These are CAATTs which are primarily used on data files. Of course, results of data
analysis can indirectly help the auditor to reach conclusions regarding the quality of programs.
However, these CAATTs do not directly test validity of programs unlike those discussed earlier.
File Interrogation Software
File interrogation involves various tests performed on a data file such as to check control
totals, duplicate entries, missing entries, abnormal transactions, select samples, etc. The tests can
be performed by using SQL statements, writing programmes specific to the system being audited,
or by using generalised audit software. Discussed below are two types of file interrogation
software.
Generalised Audit Software
The auditor may face a problem to deal with systems having diverse characteristics:
different hardware and software environments, different data structures, different record formats,
and different processing functions. With resource constraints it is often not feasible to develop
specific programs for every system that will extract, manipulate and report data required for audit
purposes. For this reason generalised audit software has been developed that is capable of
handling a wide variety of different systems. With the development and marketing of generalized
audit software like ACL31 and IDEA32, the auditor has been provided with a powerful tool that
can add tremendously to the auditor’s efficiency with minimum IT-skill requirement.
The various analytical techniques that can be employed over data using
generalized audit software for audit conclusion are:
• Reasonableness and Completeness tests
• Gap and duplication tests
• Period over period and similar comparisons
• Regression analysis
• Statistical analysis
• Transaction matching
• Data mining
Specialised Audit Software
Some types of audit software packages are now available that are oriented toward a
specific industry in which an auditor works. They differ from the generalised audit software
discussed earlier in two ways.
First, since they are oriented toward a particular industry, they provide highlevel
commands that invoke common audit functions needed within the industry. For example, in the
banking industry, they might use a single command to invoke logic that would check for account
kiting. If generalised audit software were used to check for kiting, several commands might be
required to express the logic needed for various tests.
Second, industry-specific audit software may run on a smaller number of
hardware/software configurations than generalised audit software. Indeed, industryspecific audit
software may have been developed to access the data maintained by a specific generalised
application package that is in widespread use within the industry. Accordingly, the file
definitions, record definitions, and field definitions used by the application package may be
incorporated in the audit software package, and so do not have to be defined by the auditor each
time the audit software package is run.
Appendix 3.1
System Development Life-Cycle Risks
Objective: To obtain application to specified standards, at reasonable cost, within budget and by
deadlines.
Risks are that:-
• application do not meet user needs or requirements;
• application are not available when required or supplier fails to deliver;
• application are not of the required quality;
• application are purchased without adequate authorisation;
• application are purchased at inflated prices;
• government/legal procurement directives/legislation are not observed;
• inadequate business case;
• maintenance arrangements give poor value for money.
Objective: To obtain services from a supplier in accordance with a specified set of terms
governing requirements, obligations and remuneration.
Risks include:-
• failure to maintain service levels;
• monopolistic relations develop;
• contracts inadequate for the enforcement of supplier obligations,
• confidentiality of client data;
• inadequate management of the contract;
• escalating cost.
Appendix 3.2
Reviewing System Development: A Sample Audit Programme

A. GENERAL

CONTROL
OBJECTIVES AUDIT CONSIDERATIONS Y N REMARK

1.1 Information Strategic Plan exist.

To ensure that:
1.2 Formation of ICT Steering Committee, ICT
a. Systemsare Technical Committee & Project Team.
developed according 1.3 Ensure that all Federal Circulars
to Government Rules pertaining to the system development are complied with.
& Regulations.
1.4 The deliverables at each phase are included in
the contracts.
1.5 Transfer of Technology (TOT). Auditee’s
b. Government interest isICT personnel are able to maintain and measured the
taken care of inbasic operation of the system.
formulation of the contract. 1.6 Training.
1.7 Ownership.
(* This contract should be1.8 Audit requirements:
referred to Unlimited Access to the system
throughout the audit) Audit trails
Embedded audit module
Security
1.9 Progress payment.
1.10Disaster Recovery Plan.
B. INITIATION

CONTROL
OBJECTIVES AUDIT CONSIDERATIONS Y N REMARK

2.1 Analysis of the project costs and benefits

To ensure that: prepared to evaluate the economic feasibility of each
alternative.
1. Systems developed are
approved and implemented  Costs & benefit analysis
if they are justifiable for  Time & costs estimates
economic or other sound  Impact study
reasns.  Technological advance
 User requirements
 Risk for successful completion
2.2 The feasibility study reports are reviewed by ICT
Steering Committee and that decision has been made.

2.3 Resources required to support systems after being

developed.

2.4 The project team should have the skill and time to
accomplish all designated responsibility.

2.5 The existing system should be adequately reviewed:

 Existing problem vs user needs

 New system to be based on the review and the
feasibility study
C. SYSTEM ANALYSIS
CONTROL
OBJECTIVES AUDIT CONSIDERATIONS Y N REMARK
3.1 Detailed statement of User Requirement
Systems are developed Specification (URS):
according to approved plans  Description of current problem
and procedures.  Narrative describing requirements of proposed
system
 System acceptance criteria
 Involvement of all users
 URS must be documented and approved by ICT
Steering Committee
3.2 URS is translated into Functional
Requirement Specification (FRS).
3.3 The URS are translated into logical and physical
design/system.
3.4 The design are properly documented.
3.5 The conceptual system design should include the
following:
 Context Diagram
 Entity Relationship Diagram
 Data Flow Diagram
 Processing times and general methods of operation
 Interface manually and with other systems
 Responsibility for completeness and accuracy of data
 User participation in design process
3.6 Physical design should include :
 Physical flow
 Hardware configuration
 System flow
 Files and data base specification
 Computer programme specification
 Input and report layout
3.7 To determine that the detail design includes all
material items regarding the systems and the operations
of the organisation:
 File design should be consistent and all disk and tape files
should be completely described and documented
 Sufficient audit trails should exist and access controls
should be well defined
 Input formats & source documents are defined in detail
 Validation provisions and operational controls on source
documents and input (e.g. batching, balancing, edit checks)
 Input, processing, output and operational controls should
be adequate and properly documented
 Outputs are defined in detail, should meet user needs (in
terms of content usefulness) and also meets security
provisions
D. SYSTEM DEVELOPMENT
CONTROL
OBJECTIVES AUDIT CONSIDERATIONS Y N REMARK

To ensure that design and4.1 Programming is completed according to the

development of the system detailed design and has been adequately tested
reflect the user requirements. to conform with specifications.

 Detailed systems and sub-systems specification should

be developed for the systems. They should include:
- an overall narrative description of the
systems
- the equipment configuration needed to
process the systems
- the systems software needed to support the
systems
- the interfaces with other systems
- the security and privacy requirements of the
systems
- the operational controls over the systems
- the design characteristics of the systems,
including a system flowchart
 Detailed programme specifications should be developed
for all programmes of the systems. These specifications
should include the following:
- a general narrative description of the
programme and its functions
- the equipment required to operate the
programme
- the system software needed to support the
programme
- the storage requirements of the programme,
including the amount of internal storage and
the amount and type of offline storage the
security and privacy requirements of the
programme
- the control over and within the programme
lists of constants, codes and tables used
- the operating procedures of the programme
D. SYSTEM DEVELOPMENT

CONTROL
OBJECTIVES AUDIT CONSIDERATIONS Y N REMARK
- the input record formats and descriptions
- a description of the programme’s logic, including
flowcharts and decision tables, supplemented by
narrative explanations
- the output record formats and description
- the logical and physical characteristics of all data bases
used by the programme, including file layout and data
element definitions
- source programme listing
- object programme listing

 Detailed specifications should be developed for databases used by

the computer-based system. These specification should include the
following:
- the data base identification
- the system using the data base
- the labelling and tagging convention used when the
data base is accessed
- any special instruction for using it
- the system software needed to support it
- its logical characteristics
- its physical characteristics
D. SYSTEM DEVELOPMENT

CONTROL
OBJECTIVES AUDIT CONSIDERATIONS Y N REMARK

 Systems and programmes should be adequately

tested by ICT personnel and should be acceptable to
the users:
- Detail development testing
-unit testing
-integration test
-system test

- test data prepared to test the wide

range of valid and invalid transactions.
- test results to be reviewed and
approved by users and ICT Technical
Committee (results can be compared
with planned or parallel system results)
complete record of problems detected
during testing
- sufficient resources allocated to tests
- formal systems acceptance procedures
- sign off by users
 System Documentation, such as users Manuals,
Operational Manual are produced

 Procurement of hardware and software according to

specification

 Training for various users delivered

E. IMPLEMENTATION

CONTROL
OBJECTIVES AUDIT CONSIDERATIONS Y N REMARK

To ensure that: 5.1 Detailed implementation plan is prepared to ensure

adequate control is maintained during the conversion from the
1. The managementold systems to the new systems.
acceptance over the systems
is secured. (Only tested and - Detailed implementation plan to include
approved systems are phases such as, functional
accepted and established). specifications,programming, testing
parallel running, conversion, training and
2. All programmes documentation, impact of
documentations, operation hardware/software, site preparation and
manuals and user manuals forms design
are complete and ready for - Formal procedures for approval and
use. acceptance by all parties (management,
ICT department, users)
- Detailed conversion plan which cover
systems testing, initial files creation,
reconciliation, training of ICT and user
personnel, time and manpower
requirements, and instructions or user
manuals
- Adequate back-up is available to recreate
files in the event there are problems
encountered during conversion
(unmatched totals, missing data, etc)
- Pilot testing on the system prototype
- Final acceptance test
-stress test
-volume test
-security test
- End user training are given

F. MAINTENANCE

CONTROL
OBJECTIVES AUDIT CONSIDERATIONS Y N REMARK

To ensure that 6.1 Cost of operation should be recorded, analyses and

procedures are in place somonitored.
that processing may be done
smoothly and accurately.6.2 Procedures to monitor and control system charges are
System established and record of the charges are properly kept.
modifications are6.3 Disaster recovery plan should be
G. POST IMPLEMENTATION REVIEW
CONTROL
OBJECTIVES AUDIT CONSIDERATIONS Y N REMARK

To ensure that systems meet7.1 Theeffectiveness of systems are regularly

user monitored and that system meets users requirement
requirements and achieved - Interviewing users
their objectives. - Reviewing output reports
- Examination of computer usage reports
- System response time
- Examine error rates on edit and file
maintenance report
7.2 Aspect of project management
- Time over run
- Cost over un
- Performance standard met