Application controls testing in an integrated audit

Transcription

1 Application controls testing in Application controls testing in an integrated audit

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

3 Types of controls

4 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

5 What are the different types of controls? Type of control Manual Automated Manual controls IT-dependent manual control Application controls IT general controls Prevent Detect Support the continued Misstatement in the financial statements Objective of control functioning of automated aspects of prevent and detect controls

6 Application 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 and operating effectiveness) Sample of tests across ITGC processes to ensure function of application controls Examples include: Edit checks Validations Calculations Interfaces Authorizations Examples include: Manage Change Logical Access IT Operations

7 Effect of ITGCs on applications controls Program changes Logical access IT operations Spread sheets Edit checks IT-dependent manual controls IT gen neral controls Electronic audit evidence Billing system A/P application Rate Calculations IT general cont trols Application controls Ad hoc reports Payroll system General ledger Tolerances Program changes Logical access IT operations

8 What are application controls?

9 What are Application Controls? Automated controls that affect the processing of 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 application s setup Often more effective than manual controls Test of one strategy may apply s Segregation of duties Manual controls IT-dependent manual controls Controls Embedded controls configurable controls IT general controls foundation Automated controls Application controls Operating systems Databases ERP l controls Company- leve

10 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 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 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, 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 of key financial data due to unauthorized access to key financial functions or data. Includes: Segregation of incompatible duties Authorization checks, limits and hierarchies Approval to post journal entries Two approvals for check printing

11 Edit check vs. validation The difference between edit checks and validation controls is often confused 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

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 at tthe application level? l? Transaction level Request/approve accurate, timely and complete recording of transactions Prepare accurate, timely and complete recording of transactions 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

15 Nature, timing and extent of application controls testing 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 Positive and negative aspects of control Identify any dependencies on other controls

17 Nature, timing, and extent of testing Timing i and Extent t By recognizing that application controls operate in a systematic ti manner, we may be able to perform testing ti of application controls in conjunction with the walkthrough for each applicable transaction type and processing 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 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 Type of Application Control 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 Inspection of authorization Test of 1 Test of 1 Test of 1 Test of 1 Sample Selected Inspected Test of 1 Test of 1 Test of 1 Test of 1 Configurable (System has the capability to perform the control depending on its setup, but may have been configured differently Re-performance via walkthrough h Test of 1 Test of 1 Test of 1 Test of 1 Inspection of authorization Sample Selected

19 Benchmarking of application controls

20 Benchmarking Overview Audit strategy that may be used to extend the benefits of certain tests of application controls into subsequent audit periods A computer will continue to perform a given procedure in exactly the same way until the program is changed 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 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; 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. 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. 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 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 Application controls testing considerations

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 Determine if ITGCs are effective

24 Factors impacting reliance on application controls

25 Factors that impact reliance on application 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 Logical access deficiencies controls can lead to electronic data manipulation Operations Which controls are affected by batch processing? How are batch jobs monitored? Factors impacting application controls Dependencies Some application controls depend upon others. For example, the three-way match depends on: The application i being 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 What is the flow of data? What controls monitor the timely and effective operation of interfaces?

26 Electronic audit evidence (EAE)

27 What is electronic audit evidence (EAE)? Data generated by or processed through an application, spreadsheet dh and/or end user computing solution, lti be iti in electronic or printed form, used to support audit procedures Data used for analytical a and data analysis a s procedures es Data supporting the performance of internal controls, including key performance indicators Data that t represents substantive ti 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

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 complete 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? 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., reperforming the report, proving footings)

30 Questions?