Application controls testing in

an integrated audit

Learning objectives
Describe types of controls
Describe application
pp
controls and classifications
Discuss the nature, timing and extent of application control testing
Identify when benchmarking of application controls is appropriate
Identify
y application
pp
control testing
g scoping
p g considerations
Identify factors impacting reliance on application controls
Describe electronic audit evidence

Types of controls

Entity-level vs. process-level controls

Components of internal control

Component
Control environment
Risk assessment
Monitoring
Information and communication
Control activities

Entity level

Process/transaction level

Type of ccontrol

What are the different types of controls?

Manual

Manual controls
IT-dependent
p
manual control

Automated

IT general
controls

Application controls

Prevent

Detect

Misstatement in the financial statements

Support the continued

functioning of automated
aspects of prevent and
detect controls

Objective of control

Application
pp
controls vs. ITGCs
Application controls

IT general controls

Reside within the application and

Controls around the environment

apply to individual transactions

which support the application

Test of one strategy (but need to

assess design
d i and
d operating
ti
effectiveness)

Examples
p
include:
Edit checks
Validations
Calculations
Interfaces
Authorizations

Sample of tests across ITGC

processes to
t ensure function
f
ti off
application controls

Examples
p
include:
Manage Change
Logical Access
IT Operations

Effect of ITGCs on applications controls

Program changes

Logical access

IT operations
Edit
checks

Billing system

A/P application

Electronic
audit
evidence

Rate
Calculations

Ad hoc
reports

Tolerances

Payroll system

Program changes

General ledger

Logical access

IT operations

IT
T general conttrols

IT-dependent
manual
controls

IT gen
neral controls

Spread
sheets

Application
controls

What are application controls?

What are Application Controls?

Automated controls that
processing
g of
affect the p
individual transactions
Can be characterized as
either embedded or
configurable

Often more effective than

manual controls
Test of one strategy may
apply

Automated
controls

IT-dependent
manual controls

Application
controls
level controls

Embedded controls
configurable controls

IT general controls foundation

Operating systems

Databases

ERP

Company-

Embedded control is
programmed within an
application to be performed
Configurable control is
performed depending on an
applications setup

Manual
controls

Segregation of dutiess

Controls

Classifications of application controls

Application controls are commonly grouped into five categories
Type
Edit Checks

Validations
Calculations

Description

Examples

Limit risk of inappropriate input, processing or output of

data due to field format

Limit risk of inappropriate input,

input processing,
processing or output of
data due to the confirmation of a test

Ensure that a computation is occurring accurately

Interfaces

Authorizations

Limit risk of inappropriate input,

input processing or output of
data being exchanged from one application to another

Limit the risk of inappropriate input, processing or output

of key financial data due to unauthorized access to key
financial functions or data. Includes:
Segregation of incompatible duties
Authorization checks, limits and hierarchies

Required fields
Specific data format on input
Three-way
Three
way match
Tolerance limits
Accounts receivable aging
Pricing calculations
Transfer of data between systems
Error reporting during batch runs
Approval to post journal entries
Two approvals
pp
for check p
printing
g

Edit check vs. validation

The difference between edit checks and validation

controls
t l is
i often
ft confused
f
d
Edit check
Limit risk of inappropriate input,
processing or output of data due to
field format

Validation
Limit risk of inappropriate input,
processing, or output of data due to the
confirmation of a test

Edit check example

Edit check control:

the application
requires a unique
customer purchase
order number to be
entered into the
sales order

Validation example

Validation control:
the system prevents
the entry of
incorrect product
numbers on sales
orders

SoD ITGC vs. application level

What is the difference between SoD at the ITGC level and SoD
att th
the application
li ti
level?
l
l?
Transaction level

Request/approve accurate, timely and complete recording of transactions

P
Prepare
accurate,
t timely
ti l and
d complete
l t recording
di off transactions
t
ti
Move programs in and out of production
Monitor accurate, timely and complete recording of transactions

System change management level

Request/approve program development or

program change
Program the development or change
Move programs in and out of production
Monitor program development and changes

System logical access level

Requesting access, approving access, setting

up access, and monitoring access
violations/violation attempts
Performing rights of a privileged user and
monitoring use of a privileged user

Nature, timing and extent of application

controls
t l testing
t ti

Nature, timing, and extent of testing

Nature

Nature of testing will depend on if the control is embedded or

configurable
Configurable application control:
Inspect configuration of each significant transaction type (can be
performed via walkthrough also)
Consider override capability

Other menu and record level functionality

Generally can be viewed within a configuration screen or via a system

generated report
Embedded application control:
Walkthrough of each significant transaction type
Consider override capability
Positive and negative aspects of control

Identify any dependencies on other controls

Nature, timing, and extent of testing

Ti i and
Timing
d Extent
E t t

By recognizing that application controls operate in a

systematic
t
ti manner, we may be
b able
bl tto perform
f
ttesting
ti off
application controls in conjunction with the walkthrough for
each applicable
pp
transaction type
yp and p
processing
g
alternative.
We perform tests to obtain evidence that the application
controls operated effectively throughout the period of
reliance.
Testing
g ITGCs is the most effective way
y to obtain
evidence that the application controls have continued to
operate throughout the period.

Relationship Between Application Controls and

Testing Techniques
Characteristic of the
Application Control

Embedded (System is
programmed to perform
the control as a result of
either custom coding or
packaged delivery of that
functionality.)

Nature of
Application
Control

Re-performance
via walkthrough

Type of Application Control

Edit

Validation

Calculation

Interface

Test of 1

Test of 1

Test of 1

Test of 1

Inspection of
authorization

Inspected
Configurable (System has
the capability to perform
Re-performance
the control depending on
via
i walkthrough
lkth
h
its setup, but may have
been configured differently
Inspection of
authorization

Authorization

Sample Selected

Test of 1

Test of 1

Test of 1

Test of 1

Test of 1

Test of 1

Test of 1

Test of 1

Sample Selected

Benchmarking of application controls

Benchmarking
Overview

Audit strategy that may be used to extend the benefits of

certain tests of application
pp
controls into subsequent
q
audit
periods
A computer will continue to perform a given procedure in
exactlyy the same way
y until the program
p g
is changed
g

Applicable if change controls are effective

Can remain applicable if IT general controls are ineffective,
provided we can confirm that no changes have occurred to the
particular program
In most instances, procedures in subsequent years could be
limited to a walkthrough and procedures to maintain the
benchmark and would not have to include detailed testing
benchmark,

Benchmarks are generally reestablished every three to five

years

Benchmarking
Considerations

Benchmarking strategy considerations:

The extent to which the application control can be matched to defined programs within an
application;
The extent to which the application is stable (i.e., there are few changes from period to period);
Whether a report of the compilation dates (or other evidence of changes to the programs) of all
programs placed in production is available and is reliable.

E id
Evidence
considerations:
id
ti

Program/module name(s) - Recording only the application name is generally insufficient, as

each application typically represents a suite of programs. The specific program(s) should be
identified.
L
Location
ti off th
the program - Indicate
I di t where
h
th
the program/module
/ d l iis llocated.
t d
File size in bytes - Comparing this information with the previous information may indicate
whether the program has been changed.
Last change date - In most systems, this will be the date of the file in the directory or program
library listing
listing. The last change date of the executable program indicates the date of the last
change to the program that is actually processing on system. Recognize the possibility that
changes could also have been implemented to programs during the period under review prior to
the last change date.

Application controls testing considerations

Application control testing considerations

Perform risk assessment and control analysis in collaboration
with business auditors
Increases combined understanding of business process and risks
Determines focus (all applications or a specific application)
Assists in identifying
y g optimum
p
combination of controls ((manual,,
application, IT dependent)
Consider pervasiveness, sensitivity, and frequency
Detect vs. Prevent controls

Testing schedule
Combined meetings vs. IT specific meetings
Testing methodology
Nature, timing, and extent
Determine if ITGCs are effective

Factors impacting reliance on application

controls
t l

Factors that impact reliance on application

controls
t l
Overrides
Who can override controls?
How are overrides monitored?

Segregation of duties
Application level
Functional task level
ITGC deficiencies
Change management deficiencies
can lead to incorrect system
processing
p
g and calculations
Logical access deficiencies
controls can lead to electronic data
manipulation

Factors
impacting
application
controls

Operations
Which controls are affected by
batch processing?
How are batch jobs monitored?

Dependencies
Some application controls depend
upon others. For example, the
three-way match depends on:
The
Th application
li i b
being
i
configured to force the match
Adequate segregation of
duties existing within the
application
Master file access
How are master files secured?
How are changes to master data
controlled?

Interfaces
te aces
What is the flow of data?
What controls monitor the timely
and effective operation of
interfaces?

Electronic audit evidence (EAE)

What is electronic audit evidence (EAE)?

Data generated by or processed through an application,
spreadsheet
d h t and/or
d/ end
d user computing
ti solution,
l ti
b
be it iin
electronic or printed form, used to support audit procedures
Data
ata used for
o a
analytical
a yt ca a
and
d data a
analysis
a ys s p
procedures
ocedu es
Data supporting the performance of internal controls, including
key performance indicators
Data
D t that
th t represents
t substantive
b t ti audit
dit evidence
id
tto supportt
assertions for significant accounts

Aging list of accounts receivables

Spreadsheet specifying hedging transactions
List of gains and losses from sales of marketable securities

Reliance on EAE
Establishing a basis for relying on electronic data includes:
Determining the source of the electronic data (i.e., which
application produces the data)
Determining, through the identification and evaluation of internal
controls or through substantive procedures, whether the
electronic data is complete and accurate

Testing report logic

Evaluate to what extent the logic of the report or query guarantees
that the report
p is complete
p
and accurate
Test procedures are determined based on risk assessment:

What is the origin of the software?

Is the report used frequently by the client?
Can the client influence the content of the report?
Can the client edit the output
p of the report?
p
Are we sure the data in the underlying database is complete and
accurate?

Testt procedures
T
d
are based
b
d on controls
t l ttesting
ti (e.g.,
(
review
i
off
clients test documentation) or substantive testing (e.g., reperforming the report, proving footings)

Questions?