Chapter 18

Concurrent Auditing Techniques

Concurrent Auditing Techniques to collect audit

evidence at the same time as an application system undertakes processing of its production

Basic Nature of Concurrent Auditing Techniques

2 bases for collecting audit evidence Special audit modules are embedded in

application systems to collect, process, and print audit evidenced

Audit records used to store the audit evidence collected so auditors can examine this evidence at a later stage

Concurrent Auditing

Need for Concurrent Auditing Techniques

Disappearing Paper-Based Audit Trail Continuous Monitoring Required by Advance

Systems (see next Figure) Increasing Difficulty of Performing

Transaction Walkthroughs Presence of Entropy in Systems

tendency of systems toward internal disorder and eventual collapse over time

Problems Posed by Outsourced IT Systems (difficult for auditors to be there at the outsource)

EDI and Inter- organizational Info systems

Concurrent Audit Techniques Integrated test facility (dummy company

test data then analysis of authenticity, accuracy, and completeness)

Snapshot/extended record System control audit review file

(SCARF) Continuous and intermittent

simulation (CIS)

Integrated Test Facility (ITF) Verifies authenticity, accuracy, and

completeness Involves 2 major design decisions:

What method will be used to enter test data?

What method will be used to remove the effects of ITF transactions?

Methods of Entering Test Data Using ITF

2 Methods(1) Involves tagging transactions

submitted as production input to the application system to be tested

(2) Involves designing new test transactions and entering them with the production input into the application system

Entering test data

Methods of Removing the Effects of ITF Transactions

3 Methods(1) Modify the application system

programs to recognize ITF transactions and to ignore them in terms of any processing that might affect users

(2) Submit additional input that reverses the effects of the ITF transactions

(3) Submit trivial entries so the effects of the ITF transaction on output are minimal

Snapshot/Extended Record Involves software taking “pictures” of a

transaction as it flows through an application system.

Major Implementation Decisions Where to locate the snapshot points? When to capture snapshots of transactions? Items needed for reporting of the snapshot

data that is captured (timestamp, ID, time of each process)

System Control Audit Review File

The most complex technique Involves embedding audit software

modules within a host application system to provide continuous monitoring of the system’s transactions

2 major design decisions: What info. will be collected by SCARF? What reporting system will be used?

Information Collected by SCARF Application system errors Policy and procedural variances System exceptions (certain errors are allowed)

Statistical samples Snapshots and extended records Profiling data (data to build profile of users)

Performance measurement data

Structure of SCARF Reporting

Design Decisions Determining how the SCARF file

will be updated (e.g., small applications send data to the file once a day)

Choosing sort codes and report formats to be used

Choosing the timing of report preparation

Continuous & Intermittent SimulationPrimary advantages of CIS SCARF defines exceptions of interest

but CIS traps exceptions for auditors using DBMS. It does not not require modifications to the application system

Provides an online auditing capability Requires less programming instructions Less input/output overheads