Auditing Techniques for Testing CBIS Controls

1. Integrated Test Facility (ITF)

- It involves auditors establishing a mini company or dummy company on the live
files processed by an application system.
NOTES: For example, in a payroll system, auditors might establish a masterfile record for a fictitious employee. Auditors then submit test data to the
application system as part of the normal transaction data entered into the
system. They monitor the effects of their test data on the dummy entity
they have established.
2. System Control Audit Review File (SCARF)
- It involves embedding audit software modules within a host application system to
provide continuous monitoring of systems transactions.
NOTES: Leinicke et al. (1990) describe an example of how SCARF might be
used within an insurance company to detect unauthorized changes to
policyholder master records followed by subsequent fund withdrawals.
When a name-and-address change is made to a policyholder record, the
change can be recorded via SCARF. Any subsequent withdrawal of funds
above a material amount can then be monitored by SCARF and reported for
audit scrutiny. In this way a fraudulent withdrawal of funds can be
detected. For example, without authorization, an insurance company
employee may change a policy-holders name and address to their own
name and address. The employee then may fraudulently borrow money
against the policy or withdraw funds against the policy.
3. Continuous and intermittent simulation (CIS)
- Means of collecting audit evidence concurrently with application system
processing when the application system uses a database management system to
support updating and querying of application files.
NOTES: CIS has two major components. First, like SCARF, the database
management system must be able to trap transactions that are of interest
to the auditor. Koch initially proposed that the database management
system be modified to capture transactions. Some current database
management systems, however, provide facilities that allow auditors to
write their own software routines that the database management system
will execute on their behalf. Second, auditors must write software modules
that will replicate the application system processing that is of interest. The
database management system then passes the transactions it captures

concerned about the accuracy of the calculations relating to the payout

value when a customer of the financial institution pays out a loan early. The
database management system would identify a payout transaction as being
one of the transactions that interest the auditor. It would capture the
payout transaction and pass the transaction across to the audit modules.
The modules would then calculate the payout value. In the meantime, the
application system also would have calculated the payout value. The payout
value calculated by the audit modules would then be compared with the
payout value calculated by the application system. If a discrepancy existed
between the two values, an exception would be written to an audit file.
4. Audit Hooks
- Are audit routines that flag suspicious transactions. This approach is known as
real-time notification, which displays a message on the auditors terminal as
these questionable transactions occur.
5. Snapshot
- It involves taking snapshots or pictures of a transaction as it winds its way
through an application system. In essence, it is an automated version of a manual
transaction walkthrough. Snapshots are taken at material processing points in the
application system.
NOTES: Auditors must first identify these points and then embed audit
modules within the application system at these points. At each of these
points, the audit modules typically take a snapshot of the transaction just
prior to processing and a snapshot just after processing. The auditor then
has the before-image of the transaction and the after-image of the
transaction as a basis for evaluating the authenticity, accuracy, and
completeness of the application processing carried out. These snapshots
are written away to an audit file for subsequent scrutiny by the auditor.
To illustrate use of snapshot, consider an order that is input to a
manufacturers order entry system. The order may pass through a number
of processing points that are of audit significance. For example: the
customer has to be an authorized customer; the amount of the purchase
must be within certain credit limits; a discount might be given depending
upon the status of the customer and the type of product that the customer
is wanting to purchase; the order might be exploded via a bill-ofmaterials to determine the parts required to make the product ordered;
shortages of parts may invoke a purchase order being placed on a supplier.
At some or all of these points, snapshots might be taken so the auditor can
examine the veracity of processing at each point.

6. Extended Records
- These are a simple extension of the snapshot technique. Using conventional
snapshot, individual snapshots are simply written to an audit file. Auditors then
must assemble all the snapshots that pertain to a particular transaction and a
particular stream of processing that the transaction undergoes. If a large number
of snapshots are taken, assembling related snapshots can be onerous.
NOTES: The extended records technique collects all related snapshots
together in a single record. As a transaction passes through the various
snapshot points, the snapshots are appended to a record that is eventually
written to a file for audit scrutiny. Auditors then do not bear the overheads
of sorting related snapshots together. More timely scrutiny of veracity of
the transaction and the application processing stream is possible.