an in integra tegrated ted aud audit it
Lea Le arn rnin ing g obje obj ect ctiv ive es ►
Describe types of controls
►
Describe application controls and classificatio classifications ns
►
Discuss the nature, timing and extent of application control testing
►
Identify when benchmarking of application controls is appropriate
►
Identif a
►
Identify factors impacting reliance on application controls
►
Describe electronic audit evidence
lication control testin sco in considerations
Lea Le arn rnin ing g obje obj ect ctiv ive es ►
Describe types of controls
►
Describe application controls and classificatio classifications ns
►
Discuss the nature, timing and extent of application control testing
►
Identify when benchmarking of application controls is appropriate
►
Identif a
►
Identify factors impacting reliance on application controls
►
Describe electronic audit evidence
lication control testin sco in considerations
Type ypes s of contr controls ols
Entity-level vs. process-level controls
Component Control environment Risk assessment Monitoring Information and communication Control activities
Entity level
Process/transaction level
What are the different types of controls?
l o r t n o f o e p y T
Manual
Manual con trols
IT-de endent manual contro l Automated
IT general
Application controls
Prevent
Detect
Misstatement in the financial statements
Support the continued functio ning of automated aspects of pr event and detect contro ls
Objective of control
A
lication controls vs. ITGCs Application controls
IT general controls
apply to individual transactions
“Test of one” strategy (but need to assess es gn an opera ng effectiveness) Exam les include:
which support the application
Sample of tests across ITGC processes o ensure unc on o application controls Exam les include:
Edit checks
Manage Change
Validations
Logical Access
Calculations
IT Operations
Interfaces
Authorizations
Effect of ITGCs on applications controls Program changes
Logic al access
IT operations
Edit checks
Spread sheets
I
IT-dependent manual controls
s l o r t n o c l a r e
Billing system
A/P app li cati on
Electronic audit evidence
Rate Calculations
Ad hoc reports
Tolerances
e g T I
Payroll system
Program changes
General ledger
Logic al access
IT operations
g e n e r a l c o n t r o l s
Application controls
What are application controls?
What are Application Controls?
Automated controls that affect the rocessin of individual transactions Can be characterized as either embedded or
Embedded — control is programmed within an application to be performed — performed depending on an application’s setup
Often more effective than “Test of one” strategy may apply
Classifications of application controls Application controls are commonly grouped into five categories
Edit Checks
Limit risk of inappropriate input, processing or output of data due to field format , data due to the confirmation of a test
Calculations
Ensure that a computation is occurring accurately
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
►
Required fields
►
Specific data format on input
,
, data being exchanged from one application to another Authorizations
►
► ►
Tolerance limits Accounts receivable aging
►
Pricing calculations
►
Error reporting during batch runs
► ►
Approval to post journal entries Two a
rovals for check rintin
Edit check vs. validation ►
The difference between edit checks and validation contro s s o ten con use
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 th e confi rmation of a test
Edit check example
Edit check control : the application customer purchase order number to be entered into the sales order
Validation example
Validation control: 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 a e app ca on eve Transaction level ► ►
Request/approve accurate, timely and complete recording of transactions repare accurate, t me y an comp ete recor ng o transact ons
►
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 logi cal access level ►
Requesting access, approving access, setting up access, and monitoring access
►
Performing rights of a “privileged” user and monitoring use of a “privileged” user
Nature, timing and extent of application con ro s es ng
Nature, timing, and extent of testing ►
Nature of testing wi ll 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
Embedded application control: ►
Walkthrough of each significant transaction type
► ►
►
Positive and negative aspects of control
Identify any dependencies on other contr ols
Nature, timing, and extent of testing m ng an
x en
►
By recognizing that application controls operate in a systemat c manner, we may e a e to per orm test ng o application controls in conjunction with the walkthrough for each a licable transaction t e and rocessin alternative.
►
We perform tests to obtain evidence that the application reliance.
►
Testin ITGCs is the most effective wa to obtain evidence that the application controls have continued to operate throughout the period.
Relationship Between Application Controls and Characteristic of the Application Control
Embedded (System is programmed to perform the control as a result of either custom coding or packaged delivery of that functionality.)
Nature of Application Control
Re-performance via walkthrough
Type of Application Control
Test of 1
Test of 1
Test of 1
Test of 1
Inspection of authorization
Inspected Configurable (System has the capability to perform Re-performance the control depending on v a wa roug its setup, but may have been configured differently Inspection of authorization
Sample Selected
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 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 ,
Benchmarks are generally reestablished every three to five years
Benchmarking ►
Benchmarking strategy considerations: ►
The extent to which the application control can be matched to defined programs within an
►
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.
v ence cons era ons:
► ►
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 . 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)
Consider pervasiveness, sensitivity, and frequency
Detect vs. Prevent controls
Combined meetings vs. IT specific meetings
Testing methodology
Testing schedule
Assists in identif in o timum combination of controls manual, application, IT dependent)
Nature, timing, and extent
Determine if ITGCs are effective
Factors impacting reliance on application con ro s
Factors that impact reliance on application con ro s Overrides Who can override controls? ►
Segregation of duties ► Application level
ITGC defi ciencies ►
Change management deficiencies can lead to incorrect system rocessin and calculations
►
Logical access deficiencies controls can lead to electronic data manipulation
impacting application controls
Operations ► Which controls are affected by batch processing? How are batch jobs monitored? ►
Dependencies Some application controls depend ► upon others. For example, the three-way match depends on: The application 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?
Electronic audit evidence (EAE)
What is electronic audit evidence (EAE)? Data generated by or processed through an application, sprea s eet an or en user comput ng so ut on, e t n electronic or printed form, used to support audit procedures ►
Data used for anal tical and data anal sis rocedures
►
Data supporting the performance of internal controls, including key performance indicators
►
a a a represen s su s an ve au assertions for significant accounts ►
ev ence o suppor
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)
►
Determinin throu h 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 re ort is com lete 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? ►
es proce ures are ase on con ro s es ng e.g., rev ew o client’s test documentation) or substantive testing (e.g., reperforming the report, proving footings)
