Previous Table of Contents Next


Section 25
Evaluate Internal Controls

Philosophies of control in automated computer systems (as in other areas) differ. One philosophy holds that computers make few mistakes and have never defrauded systems—people, on the other hand, do defraud and do make mistakes. Therefore, if duties are properly segregated, control can be assumed to be adequate. The other philosophy holds that transactions should be controlled: if transactions are adequately controlled; so are people. There is merit in both arguments.

This part of the audit process is designed to determine whether the controls are adequate to reduce the risks to an acceptable level. In the process of making this determination, the IT auditor will be able to identify potential vulnerabilities for closer examination later in the audit process.

Few organizations have established standards for the development of internal control. Without such standards, control activities frequently do not comply with the organization’s developmental standards and requirements and become a cause for concern after a system has been operating for some time. In many instances, the extent of internal control depends on the individual experience and desires of the systems analyst or programmer.

DOCUMENT SEGREGATION OF RESPONSIBILITIES

This task examines the segregation of responsibilities within an automated application to identify areas in which one person performs two tasks and thus creates potential responsibility conflicts that can be considered control vulnerabilities. Areas to examine include:

  Organizational charts
  Job descriptions
  Department or function charters
  Procedural manuals
  System documentation

Identifying Actions. Each action that occurs during application processing should be identified. An application action usually involves one of the following functions:

  Originating a transaction
  Approving a transaction
  Entering a transaction into a computer system
  Communicating information
  Processing information
  Storing data
  Reporting data out of the computer system
  Using information

Identifying Personnel Responsible for the Actions. Everyone involved in the application processing should be listed, even if the system performs the action. If the application system is set up to approve credit automatically, for example, it is important to know which person in the organization was responsible for that process. The names of the personnel should be listed vertically on the workpaper in the order in which the actions are performed.

CONDUCT AN INTERNAL CONTROL REVIEW

The objective of this review is to identify the controls in place in the application system. Questionnaires are used to gather information about data origination, input, processing, and output. At the conclusion of this task, the IT auditor will be aware of the controls that have been established and where they are located. This information enables the IT auditor to conduct a vulnerability assessment, further investigating the identified control weaknesses to determine whether they have been converted into losses to the organization. The control review uses questionnaires that coincide with the major areas of an application system. Each questionnaire includes guidelines that explain its use and purpose. The questions indicate the items to be investigated and provide responses of yes, no, and not applicable. All responses should be indexed to the appropriate supporting documents or interview records. Positive answers represent good control practices—negative ones indicate potential control weaknesses orother vulnerabilities. A Comments column is used to explain all negative answers and identify alternative procedures. Negative answers are investigated further (in a later task) to determine the magnitude of the vulnerability.

The questionnaires are simply guides to use in identifying and documenting the existence of controls; they are not intended to be the sole investigative tool. The IT auditor should also investigate any areas that are inadequately addressed on the questionnaire, as well as those needing further study as indicated by the answers. Some questions may be repeated in two or more questionnaires because the type of control needed in processing, for example, could also be needed in storage and output. The IT auditor should remember that because the objective is to identify the totality of controls designed to reduce specific risks, implementation of the same control in more than one area of the application must be identified.

To complete this task successfully, the IT auditor must clearly understand all the questions. This understanding will help the respondent avoid misinterpreting the question and thus providing the wrong response. Although it is important that the questionnaire be complete, the IT auditor should not rely too heavily on it, thereby neglecting to do additional probing.

DEVELOP INTERNAL CONTROL DIAGRAMS

Although the information provided by the questionnaires in the previous task is valuable in assessing the adequacy of controls, it is rarely specific enough for a thorough control assessment. The objective of this task is to show where the internal control operates in the application. Entering the controls in a work flow diagram indicates whether the control over the flow of data is adequate to reduce the perceived risks. Selected key transactions should also be identified, their flow documented, and the appropriate controls indicated wherever they operate in the flow. Completing this task provides documentation on the system of controls that can be used as input to the control assessment.

Completing the Work Flow Control Diagram. This diagram is essentially a work flow diagram with controls superimposed on it. The following procedures should be used in completing work flow control diagrams:

  Every process, storage, and movement of data represents a point of risk; there should be at least one control at each of these points.
  Only the key controls—those that management relies on for the correctness of processing—should be indicated on the diagram.
  Controls should be summarized wherever practical. The phrase “data validation,” for example, can be used to summarize the possibly hundreds of individual controls that check and evaluate data entering an automated system.
  The selected controls should be those identified on the questionnaires.

Documenting Transactions on Work Flow Diagrams. It may be necessary to indicate the different processing paths taken by the various parts of the transaction. For example, an invoice may contain both product and sales-tax information, which may enter different systems and thus be subject to different controls. Each action performed on a transaction represents a risk point. It is at those points that controls should occur. The workpaper should provide room to record the transaction and show the segments of an application system. The IT auditor should enter the name of the transaction and, in each of the system segments, indicate the control over that transaction at that point. For example, an authorization control in data origination would be documented in that column next to the transaction to which it applied. The following are guidelines for completing the diagram.

  At a minimum, one control should be located in each area of transaction processing.
  Business transactions rather than computer records should be used; this reduces the number of individual transactions shown.
  Only the most critical financial transactions should be selected.
  If transaction processing divides, only segments with significant financial implications should be followed.
  The controls identified should be the key controls—where practical, they should be consolidated.


Previous Table of Contents Next