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

What are the different types of controls?

Type of c control

Manual

Manual controls IT-dependent p manual control

Automated

Application controls

IT general 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
Reside within the application and
apply to individual transactions

IT general controls
Controls around the environment
which support the application

Test of one strategy (but need to

assess design d i and d operating ti effectiveness)

Sample of tests across ITGC

processes to t ensure function f ti of f application controls

Examples p include: Edit checks Validations Calculations Interfaces Authorizations

Examples p include: Manage Change Logical Access IT Operations

Effect of ITGCs on applications controls

Program changes Logical access IT operations
Edit checks

Spread sheets

IT T general cont trols

IT gen neral controls

Billing system
Electronic audit evidence

A/P application
Rate Calculations

IT-dependent manual controls

Application controls

Ad hoc reports

Tolerances

Payroll system

General ledger

Program changes

Logical access

IT operations

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
Embedded control is programmed within an application to be performed Configurable control is performed depending on an applications setup
Controls
Manual controls Automated controls

IT-dependent manual controls Embedded controls configurable controls

Segregation of duties s

Application controls
level controls
ERP

IT general controls foundation

Often more effective than manual controls Test of one strategy may apply

Operating systems

Databases

Company-

Classifications of application controls

Application controls are commonly grouped into five categories
Type Edit Checks Description 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 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

Examples 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

Validations Calculations Interfaces

Authorizations

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 at t 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 of f 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 be b able bl t to perform f t testing ti of f 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 Nature of Application Control Type of Application Control Edit Validation Calculation Interface Authorization

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

Re-performance via walkthrough

Test of 1

Test of 1

Test of 1

Test of 1

Inspection of authorization

Sample Selected

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

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 exactly y 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. 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 of f th the program - Indicate I di t where h th the program/module / d l i is l located. 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.

E id Evidence considerations: id ti

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 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 Overrides Who can override controls? How are overrides 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?

Factors impacting application controls

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

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 i in 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 t to support t 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?

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

Questions?