Application controls testing inApplication controls testing in an integrated audit

Learning objectives

Describe types of controls Describe application controls and classifications pp Discuss the nature, timing and extent of application control testing Identify when benchmarking of application controls is appropriate Identify application control testing scoping considerationsy pp g p g 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

Components of internal control

Risk assessment

Monitoring

Information and communication

Control activities

What are the different types of controls?c

o

n

t

r

o

l Manual

IT-dependent

Manual controls

T

y

p

e

o

f

c

Automated Application controls

pmanual control

IT generalcontrols

Prevent Detect Support the continued functioning of automated

controls

Objective of control

Misstatement in the financial statements aspects of prevent and detect controls

Application controls vs. ITGCspp

Application controls Reside within the application and

IT general controls Controls around the environmentReside within the application and

apply to individual transactions

Test of one strategy (but need to d i d ti

Controls around the environment which support the application

Sample of tests across ITGC t f ti fassess design and operating

effectiveness)

Examples include:

processes to ensure function of application controls

Examples include:p Edit checks Validations Calculations

p Manage Change Logical Access IT Operations

Interfaces Authorizations

Effect of ITGCs on applications controls

Program changes Logical access IT operations

IT

Spread sheets

Editchecks

Application controls

IT-dependent manual controls

A/P application

n

e

r

a

l

c

o

n

t

r

o

l

s

T general cont

Electronic audit

evidence

RateCalculations

Billing system

I

T

g

e

n

trols

Ad hocreports

TolerancesGeneral ledgerPayroll system

Program changes Logical access IT operations

What are application controls?

What are Application Controls?

Automated controls that affect the processing of Controlsp gindividual transactions

Can be characterized as either embedded or configurable

ControlsManualcontrols

Automatedcontrols

configurable Embedded control is

programmed within an application to be performed

Configurable control isEmbedded controls

configurable controls

s

l

c

o

n

t

r

o

l

s

IT-dependent manual controls controls

Application

Configurable control is performed depending on an applications setup

Often more effective than manual controls

S

e

g

r

e

g

a

t

i

o

n

o

f

d

u

t

i

e

s

C

o

m

p

a

n

y

-

l

e

v

e

IT general controls foundation

Operating systems Databases ERP

manual controls Test of one strategy may

apply

Classifications of application controls

Type Description Examples

Application controls are commonly grouped into five categories

Type Description Examples

Edit Checks Limit risk of inappropriate input, processing or output of data due to field format

Required fields Specific data format on input

Validations Limit risk of inappropriate input processing or output of Three way matchValidations Limit risk of inappropriate input, processing, or output of data due to the confirmation of a test

Three-way match Tolerance limits

Calculations Ensure that a computation is occurring accurately Accounts receivable aging Pricing calculations

Interfaces Limit risk of inappropriate input processing or output of Transfer of data between systemsInterfaces Limit risk of inappropriate input, processing or output of data being exchanged from one application to another

Transfer of data between systems Error reporting during batch runs

Authorizations Limit the risk of inappropriate input, processing or output of key financial data due to unauthorized access to key

Approval to post journal entries Two approvals for check printing

financial functions or data. Includes: Segregation of incompatible duties Authorization checks, limits and hierarchies

pp p g

Edit check vs. validation

The difference between edit checks and validation t l i ft f dcontrols is often confused

Edit check ValidationEdit check ValidationLimit risk of inappropriate input, processing or output of data due to field format

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 uniquerequires a unique customer purchase order number to be entered into the sales order

Validation example

Validation control:the system preventsthe 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 t th li ti l l?at the application level?

Transaction level Request/approve accurate, timely and complete recording of transactions

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

System logical access level Requesting access, approving access, setting

up access, and monitoring access violations/violation attempts

System change management level Request/approve program development or

program change violations/violation attempts

Performing rights of a privileged user and monitoring use of a privileged user

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

Nature, timing and extent of application t l t ticontrols testing

Nature, timing, and extent of testingNatureNature 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 reportgenerated report

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

Identify any dependencies on other controls

Nature, timing, and extent of testingTi i d E t tTiming and Extent By recognizing that application controls operate in a

t ti b bl t f t ti fsystematic manner, we may be able to perform testing of application controls in conjunction with the walkthrough for each applicable transaction type and processing pp yp p galternative.

We perform tests to obtain evidence that the application controls operated effectively throughout the period ofcontrols operated effectively throughout the period of reliance.

Testing ITGCs is the most effective way to obtain g yevidence that the application controls have continued to operate throughout the period.

Relationship Between Application Controls and Testing Techniques

Characteristic of the Application Control

Nature of Application

Control

Type of Application Control

Edit Validation Calculation Interface Authorization

Testing Techniques

Control Edit Validation Calculation Interface Authorization

Embedded (System is programmed to perform the control as a result of

Re-performance via walkthrough Test of 1 Test of 1 Test of 1 Test of 1

either custom coding or packaged delivery of that functionality.)

Inspection of authorization Sample Selected

Configurable (System has the capability to perform the control depending on

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

Re-performance i lkth h Test of 1 Test of 1 Test of 1 Test of 1its setup, but may have

been configured differentlyvia walkthrough

Inspection of authorization Sample Selected

Benchmarking of application controls

BenchmarkingOverviewOverview Audit strategy that may be used to extend the benefits of

certain tests of application controls into subsequent audit pp qperiods

A computer will continue to perform a given procedure in exactly the same way until the program is changed y y p g 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 testingbenchmark, and would not have to include detailed testing

Benchmarks are generally reestablished every three to five years

BenchmarkingConsiderationsConsiderations Benchmarking strategy considerations:

The extent to which the application control can be matched to defined programs within an application;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 id ti Evidence considerations: 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 ti f th I di t h th / d l i l t d Location of the program - Indicate where the program/module is located.

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 The last change date of the executable program indicates the date of the lastlibrary 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 optimum combination of controls (manual, y g p ( ,

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 t lcontrols

Factors that impact reliance on application t lcontrols

Segregation of duties Application level Functional task level

Overrides Who can override controls? How are overrides monitored?

ITGC deficiencies Change management deficiencies

can lead to incorrect system processing and calculations

Functional task level

Dependencies Some application controls depend

upon others. For example, the three-way match depends on:

Th li i b i

How are overrides monitored?

Factorsp g Logical access deficiencies

controls can lead to electronic data manipulation

The application being configured to force the match

Adequate segregation of duties existing within the application

Factors impacting application

controls

Interfaces

Master file access How are master files secured? How are changes to master data

controlled?

Operations Which controls are affected by

batch processing? How are batch jobs monitored?

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, d h t d/ d ti l ti b it ispreadsheet and/or end user computing solution, be it in

electronic or printed form, used to support audit procedures Data used for analytical and data analysis procedures ata used o a a yt ca a d data a a ys s p ocedu es Data supporting the performance of internal controls, including

key performance indicators D t th t t b t ti dit id t t Data that represents substantive audit evidence to support 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 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 is complete and accuratep p

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 of the report?p p Are we sure the data in the underlying database is complete and

accurate?

T t d b d t l t ti ( i fTest procedures are based on controls testing (e.g., review of clients test documentation) or substantive testing (e.g., re-performing the report, proving footings)

Questions?Questions?