Concurrent Auditing Techniques 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 (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 (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 Simulation Primary 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