«Item type text; Dissertation-Reproduction (electronic) Authors DUNN, THURMAN STANLEY. Publisher The University of Arizona. Rights Copyright © is ...»
Hardware. Hardware includes the physical equipment in a system. The physical equipment in a system may range from a small central processing unit (CPU) with a few peripheral input and output devices (e.g., card readers, tape drives, disk drives, card punches, and printers) to banks of huge CPUs with thousands of peripheral units including remote terminals, front-end minicomputers, etc., in addition to the above types of devices.
Software. Software includes the computer programs and routines that direct and faci 1itate the operation of the hardware. Software typically falls into two categories, systems software and applications software. The auditor or examiner should be familiar with both types.
Systems programs generally fall into two categories, either operating systems which are used to process one or more appl ications programs simultaneously or data management systems which handle standardized data functions for applications programs. Systems programs are usually developed by equipment manufacturers or by software companies.
Applications programs are made up of instructions which cause the computer system to perform specific data processing tasks. These programs have typically been written by the user of the system or by a software developer for a specific application. However, with the advent of the minicomputer and microcomputer markets, thousands of applications software packages are being developed and sold "off-theshelf".
Documentation. Documentation describes the activities surrounding a computer system. This documentation covers operations of the system; application and systems software and procedures.
Unfortunately, documentation is all too often inadequate, particularly for appl ications software. In fact, in many cases, the documentation is totally inadequate if it exists at all. In these cases it might be necessary to read the code in the computer programs to determine what will happen when they are processed, or process comprehensive test decks and observe what happens.
Documentation generally falls into the following categories:
Functional Description. The functional description describes the application in terms of the functions it performs. This document should address the operations performed. For example, for an accounting system the description should describe incoming documents or data, required reports and information and the processes required to produce them.
Systems Documentation. This documentation generally describes the processes and flow of data through the computer system. As opposed to the functional description which concentrates on the functions performed, the systems documentation is oriented to the processes required to perform the functions including descriptions of input, output and file data.
Program Documentation. The program documentation shows the specific steps and logic of the computer program through narrative 1istings and program flowcharts, data formats including input, output, file and record layouts.
Operations Manuals. These manuals contain instructions and information needed by the computer operator to run the system.
User Documentat i on. These documents instruct the user in the use of the system. They typically describe inputs, output listings, reports, error codes, correction procedures and processing cycles necessary to successfully operate the system.
People. The people involved in a computer system vary from organization to organization. However, the functions performed are similar even though they may be performed by people with different titles.
Functional Manager. The Functional Manager, from the users group, excercises control over and typically has responsibility for the function being performed. Thus, for example, the Accounting Manager, Vice President of Accounting, Chief Accountant, Director of Accounting, etc., might control the function of accounting and be responsible for accounting information and reports.
EDP Manager. Typically, the EDP Manager is responsible for overall systems planning, development and operation of systems, equipment and processes.
Systems Analyst. The Systems Analyst usually evaluates existing systems, designs new systems and prepares specifications for programmers. The Systems Analyst may be part of the user's group although, typically he or she belongs to the EDP group.
Programmer. The Programmer, generally, prepares detailed flowcharts, decision charts, etc., of system logic; programs;
develops; debugs and documents computer programs.
Computer Operator. This individual operates the computer eqUipment and runs computer programs according to operating instructions.
Data Entry Operator. The Data Entry Operator prepares data for entry into the computer through such devices as keypunch, keyto-tape, key-to-disk machines and on-1 ine data entry devices such as remote terminals.
Librari an. The Librari an, typically, maintains systems documentation, programs and files.
Data (Files). Data include transactions and related information that are entered into a system, stored, processed or produced by a system. A collection of data with certain common characteristics is commonly referred to as a fi leo The fi les are processed through the computer equipment in accordance with the software instructions to produce information, reports, additional files, etc.
There are usually two types of files involved in a process.
First, is the master file which contains information for given classes of data. Second, is the transaction file which is processed against the master file to update the master files.
Procedures. The procedures surrounding a system dictate when and how data is processed through the system. In addition to normal processing, these procedures cover emergency or unusual operations such as loss of data files, loss of power to the computer, etc.
Diminished Audit Trail In their book on "Management Fraud - Detection and Deterrence", Elliott and Willingham (1980) discuss the prospect of diminished source documentation. They observe that;
Computers are des i gned to reduce paper work and as systems become more sophisticated they el iminate more and more of the backup paper documentation which can faci 1itate controls and audit testing. Source documentation may increasingly be eliminated by the expanded use of real-time systems for accounting. Unlike batch-operated systems, which process information when it is input from batches of source documents (e.g., sales invoices), real-time systems allow the operator to input data directly into the processing unit by a keyboard and have it processed without delay. In many situations there need be no source document.
The observations made by Elliot and Willingham represent a major challenge to today's auditor. Although it may be possible to design systems, even real-time systems, with audit trails, the auditor is faced with the fact that these trails may not exist. This is particularly true in a computer fraud investigation since part of the fraud scheme may be to cover up audit trails which do 'exist. Ideally, the auditor should be integrally involved in the design of new EDP systems, ensuring that they are auditable and properly controlled.
However, the computer fraud investigator should be able to deal with inadequate audit trails and be suspicious of even those which appear adequate.
Numerous articles in the current literature on EDP auditing suggest that the conventional audit trail may be eliminated altogether in future systems and auditors are advised to develop procedures that are not dependent on these trail s (Cook and Wi nk 1e 1980). However, alternative audit procedures have not been easy to devise since procedures designed to' trace transactions back through systems to source documents using an audit trail represent basic operating technique for auditors. Further, it is not a foregone conclusion that audit trails will completely disappear from EDP applications.
While the technology seems to be pushing development in this direction due to increased operating efficiencies such as speed of information delivery and reduction of paper usage, there are val id reasons for maintaining audit trails. Some of the reasons are the use by management of transactions detail, internal and external audit requirements, safeguards against system error or breakdown, and requirements of the Internal Revenue Service. In this regard, Cook and Winkle cite the position of the IRS as stated in Revenue Procedure 64-12 under the heading "A.D.P.
Supporting Documents and Audit Trails - The audit trail should be designed so that the details underlying the summary accounting data, such as invoices and vouchers, may be identified and made available to the Internal Revenue Service upon request.
Recorded or Reconstructible Data. The records must provide the opportunity to trace any transaction back to the original source or forward to a final total. If printouts are not made of transactions at the time they are processed, then the system must have the ability to reconstruct these transactions Basically, three procedures for auditing in an EDP environment have evolved over the past few years; Auditing around the computer;
Auditing through the computer and Auditing with the computer. The following discussion is patterned largely after Cook and Winkle, however, these procedures are quite common in the literature.
Auditing Around the Computer Where a detailed audit trail exists auditors may be able to perform examinations without utilizing the computer. The basic procedure resembles the non-EDP audit in that print-outs of the details of account balances and the associated transaction print-outs are first obtained. Then, specific transasctions are selected and traced back through the accounting records to appropriate source documents.
In certain applications this procedure may provide adequate evidence upon which to form an opinion with respect to the data. As long as the auditor is fully informed regarding the 1 imitations and potential pitfalls of such an approach and works within these constraints, there is no reason not to audit around the computer.
A couple of observations should be made, however, regarding the use of this approach in investigating for computer fraud. First, it should be noted that the approach is oriented mostly to the evaluation Although transaction manipulation is certainly a of transactions.
significant computer fraud scheme as evidenced by its prominence in
reported fraud cases, it is only one of several possible scheme types.
Further, as indicated earlier part of the fraud scheme might be to purposely cover or distort the audit trail. Thus, while the technique of auditing around the computer might be useful in the computer fraud investigation in certain circumstances it will most likely have to be augmented with other techniques.
Auditing Through the Computer If little hard copy exists and a discernible audit trail does not exist, the technique of auditing around the computer is likely to be inappropriate in a general audit and certainly will be of little use in a computer fraud investigation. An approach which might be useful in this situation is that of auditing through the computer. This technique uses the computer hardware and software to test data. Two cOllll1on methods of auditing through the computer are the use of test data and reprocessing.
Use of Test Data Using this approach, the auditor develops data similar to that normally processed by the system. Then, these specially developed data are processed through the system in a controlled environment. Finally, the resulting processed information is compared with predetermined results to ascertain whether the test data were processed properly.
The test data should include both valid and invalid conditions.
This approach provides evidence regarding the operation of the computer system at a given point in time. It provides little evidence regarding the operation of the system over time, for example during the entire period under examination. "In order to satisfy auditing standards, use of the Test Data method must be coupled with an examination of source documents and other source evidence supporting the records that are being produced." (Davis 1968).
Reprocessing The Reprocessing approach requires that samples of actual data from the period under examination be reprocessed under controlled conditions. To perform this operation the investigator either uses a program in the EDP department that previously has been tested or uses a duplicate program over which the auditor maintains control. Upon completion of the reprocessing, the results are compared with the original data, as recorded in the system's records. One advantage to this approach over the Test Data approach is that the auditor may draw inferences regarding both the operation of the computer program and the validity of the data being processed.
Auditing through the computer has numerous advantages for the computer fraud investigator over auditing around the computer. However there are computer fraud scheme/perpetrator combinations which might not be detected through this approach. For example certain file manipulation or improper operation schemes may not be detected through either the Test Data or Reprocessing approaches.
Auditing with the Computer Computer programs can be devised so that various audit tasks can be efficiently performed using either internal or external EDP equipment. Generalized computer audit programs are available which accomplish a wide range of audit tasks and are adaptable to a number of different EDP systems.
Use of generalized computer audit programs may provide increased access to the data stored in the system. They can also be used to present the data in a more meaningful format than might otherwise be easily achieved.
The following audit tasks are commonly performed by generalized
computer audit programs:
1. Statistical and judgemental selection of audit samples.
2. Mathematical verification of footings, extensions, and other calculations.
3. Multiple regression calculations or other procedures to select items for analytical review.
4. Data manipulation chores such as computation of subtotals, summarization, listing selectively, etc.
5. Examining records for completeness and correctness.
6. Comparing data that appear on separate files.