IT AUDIT MANUAL

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:

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.