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 Entity level Process/transaction level

Control environment

Risk assessment

Monitoring

Information and communication

Control activities
What are the different types of controls?

Manual controls
Manual
Type of ccontrol

IT-dependent
p
manual control

IT general
Automated Application controls
controls

Support the continued

Prevent Detect functioning of automated
Misstatement in the financial statements 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 Sample of tests across ITGC

assess design
d i andd operating
ti processes to
t ensure function
f ti off
effectiveness) application controls

Examples
p include: Examples
p include:
Edit checks Manage Change
Validations Logical Access
Calculations IT Operations
Interfaces
Authorizations
 Effect of ITGCs on applications controls

Program changes Logical access IT operations

Edit
Spread checks
sheets

IT
T general conttrols
neral controls

Billing system A/P application

IT-dependent Electronic Rate
Application
manual audit Calculations controls
evidence
controls
IT gen

Ad hoc Tolerances
reports Payroll system General ledger

Program changes Logical access IT operations

What are application controls?
What are Application Controls?

Automated controls that

affect the p
processingg of Controls
individual transactions
Manual Automated
Can be characterized as controls controls
either embedded or
configurable IT-dependent Application
Embedded control is manual controls controls
programmed within an Embedded controls
application to be performed

level controls
configurable controls
Configurable control is

Segregation of dutiess
performed depending on an IT general controls foundation
applications setup

Company-
Often more effective than Operating systems Databases ERP

manual controls
Test of one strategy may
apply
Classifications of application controls

Application controls are commonly grouped into five categories

Type Description Examples
Edit Checks Limit risk of inappropriate input, processing or output of Required fields
data due to field format Specific data format on input

Validations Limit risk of inappropriate input,

input processing,
processing or output of Three-way
Three way match
data due to the confirmation of a test Tolerance limits
Calculations Ensure that a computation is occurring accurately Accounts receivable aging
Pricing calculations
Interfaces Limit risk of inappropriate input,
input processing or output of Transfer of data between systems
data being exchanged from one application to another Error reporting during batch runs

Authorizations Limit the risk of inappropriate input, processing or output Approval to post journal entries
of key financial data due to unauthorized access to key Two approvals
pp for check pprinting
g
financial functions or data. Includes:
Segregation of incompatible duties
Authorization checks, limits and hierarchies
Edit check vs. validation

The difference between edit checks and validation

controls
t l isi often
ft confused
f d

Edit check Validation

Limit risk of inappropriate input, Limit risk of inappropriate input,
processing or output of data due to processing, or output of data due to the
field format 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 andd 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 System logical access 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
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 beb able
bl tto perform
f ttesting
ti off
application controls in conjunction with the walkthrough for
each applicable
pp transaction type
yp and p processingg
alternative.
We perform tests to obtain evidence that the application
controls operated effectively throughout the period of
reliance.
Testingg ITGCs is the most effective wayy to obtain
evidence that the application controls have continued to
operate throughout the period.
Relationship Between Application Controls and
Testing Techniques
Characteristic of the Nature of Type of Application Control
Application Control Application
Control Edit Validation Calculation Interface Authorization

Embedded (System is
Re-performance
programmed to perform Test of 1 Test of 1 Test of 1 Test of 1
via walkthrough
the control as a result of
either custom coding or
packaged delivery of that Inspection of
functionality.) Sample Selected
authorization

Inspected Test of 1 Test of 1 Test of 1 Test of 1

Configurable (System has

the capability to perform
the control depending on Re-performance
Test of 1 Test of 1 Test of 1 Test of 1
its setup, but may have via
i walkthrough
lkth h
been configured differently

Inspection of
Sample Selected
authorization
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
Segregation of duties Overrides
Application level Who can override controls?
Functional task level How are overrides monitored?

ITGC deficiencies Dependencies

Change management deficiencies Some application controls depend
can lead to incorrect system upon others. For example, the
processing
p g and calculations three-way match depends on:
Logical access deficiencies
Factors The
Th application
li i b being
i
configured to force the match
controls can lead to electronic data impacting Adequate segregation of
manipulation application duties existing within the
application
controls
Operations Master file access
Which controls are affected by How are master files secured?
batch processing? How are changes to master data
How are batch jobs monitored? 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 aanalytical
a yt ca a
andd data a
analysis
a ys s pprocedures
ocedu es
Data supporting the performance of internal controls, including
key performance indicators
Data
D t that
th t representst 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., re-
performing the report, proving footings)
Questions?