Application controls testing in an integrated audit

(1)

Application controls testing in

an integrated audit

(2)

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 considerations

y pp

g

p g

►

Identify factors impacting reliance on application controls

►

Describe electronic audit evidence

(3)

(4)

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

(5)

What are the different types of controls?

control

Manual

IT-dependent

Manual controls

Ty

pe of

c

Automated

Application controls

p

manual control

IT general

controls

Prevent

Detect

_{functioning of automated}Support the continued

controls

Objective of control

Misstatement in the financial statements aspects of prevent and detect controls

(6)

Application controls vs. ITGCs

pp

Application controls



Reside within the application and

IT general controls



Controls around the environment

Reside 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

f

assess 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

(7)

Effect of ITGCs on applications controls

Program changes Logical access IT operations

IT Spread sheets Edit checks

Application

controls

IT-dependent

manual

controls

A/P application n eral controls T general con t Electronic audit evidence Rate Calculations Billing system IT ge n trols Ad hoc reports Tolerances General ledger Payroll system

(8)

(9)

What are Application Controls?



Automated controls that

affect the processing of

p

g

_Controls

individual transactions



Can be characterized as

either embedded or

configurable

Controls

Manual

controls Automatedcontrols

configurable



Embedded

— control is

programmed within an

application to be performed



Configurable

— control is

Embedded controls configurable controls

s l cont

ro

ls

IT-dependent

manual controls Applicationcontrols

Configurable

control is

performed depending on an

application’s setup



Often more effective than

manual controls

Segregation

of dutie s Compa ny -leve

IT general controls foundation

Operating systems Databases ERP

manual controls



“Test of one” strategy may

apply

(10)

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 match

Validations 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 systems

Interfaces 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

(11)

Edit check vs. validation

► The difference between edit checks and validation

t l i

ft

f

d

controls is often confused

Edit check

Validation

Edit check

Validation

Limit 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

(12)

Edit check example

Edit check control:

the application

requires a unique

customer purchase

order number to be

entered into the

sales order

(13)

Validation example

Validation control:

the system prevents

the entry of

incorrect product

numbers on sales

orders

(14)

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

(15)

Nature, timing and extent of application

t

l t

ti

(16)

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

►

Consider override capability

►

Positive and negative aspects of control

(17)

Nature, timing, and extent of testing

Ti i

d E t

t

Timing and Extent

► By recognizing that application controls operate in a

t

ti

b

bl t

f

t ti

f

systematic 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

g

alternative.

► We perform tests to obtain evidence that the application

controls operated effectively throughout the period of

reliance.

► Testing ITGCs is the most effective way to obtain

g

y

evidence that the application controls have continued to

operate throughout the period.

(18)

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 1 its setup, but may have

been configured differently

via walkthrough

Inspection of

(19)

(20)

Benchmarking

Overview

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

certain tests of application controls into subsequent audit

pp

q

periods

► A computer will continue to perform a given procedure in

exactly the same way until the program is changed

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 testing

benchmark, and would not have to include detailed testing

► Benchmarks are generally reestablished every three to five

years

(21)

Benchmarking

Considerations

►

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 last library 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.

(22)

(23)

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

(24)

Factors impacting reliance on application

t

l

(25)

Factors that impact reliance on application

t

l

controls

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?

Factors

p 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?

(26)

(27)

What is electronic audit evidence (EAE)?

Data generated by or processed through an application,

d h t

d/

d

ti

l ti

b it i

spreadsheet 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

► Data that represents substantive audit evidence to support

assertions for significant accounts

► Aging list of accounts receivables

► Spreadsheet specifying hedging transactions

(28)

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

(29)

Testing report logic

Evaluate to what extent the logic of the report or query guarantees

that the report is

p

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 of the report?

p

► Are we sure the data in the underlying database is complete and

accurate?

T t

d

b

d

t l t ti

(

i

f

Test procedures are based on controls testing (e.g., review of

client’s test documentation) or substantive testing (e.g.,

(30)