Application controls testing in an integrated audit



Similar documents
Electronic Audit Evidence (EAE) and Application Controls. Tulsa ISACA Chapter December 11, 2014

The Information Systems Audit

Risikobaseret tilgang til revision

INTERNATIONAL STANDARD ON AUDITING 401 AUDITING IN A COMPUTER INFORMATION SYSTEMS ENVIRONMENT CONTENTS

Performing Audit Procedures in Response to Assessed Risks and Evaluating the Audit Evidence Obtained

The Use of Spreadsheets: Considerations for Section 404 of the Sarbanes-Oxley Act*

OBSERVATIONS FROM 2010 INSPECTIONS OF DOMESTIC ANNUALLY INSPECTED FIRMS REGARDING DEFICIENCIES IN AUDITS OF INTERNAL CONTROL OVER FINANCIAL REPORTING

Information Technology General Controls (ITGCs) 101

IT audit updates. Current hot topics and key considerations. IT risk assessment leading practices

4 Testing General and Automated Controls

How To Audit A Company

Guide to the Sarbanes-Oxley Act: IT Risks and Controls. Frequently Asked Questions

Article: Control Systems and Controls Testing: General Review

AN AUDIT OF INTERNAL CONTROL OVER FINANCIAL REPORTING THAT IS INTEGRATED WITH AN AUDIT OF FINANCIAL STATEMENTS:

An Examination of an Entity s Internal Control Over Financial Reporting That Is Integrated With an Audit of Its Financial Statements

INTERNATIONAL STANDARD ON AUDITING 330 THE AUDITOR S RESPONSES TO ASSESSED RISKS CONTENTS

Sarbanes-Oxley Section 404: Management s Assessment Process

New Audit Standards: How Will They Impact the Audit

Fraud and Role of Information Technology. September 2008

Project Risk and Pre/Post Implementation Reviews

The Importance of IT Controls to Sarbanes-Oxley Compliance

10-1. Auditing Business Process. Objectives Understand the Auditing of the Enteties Business. Process

Dr. Thomas Nösberger. A short overview

THE AUDITOR S RESPONSES TO ASSESSED RISKS

GUIDE TO THE SARBANES-OXLEY ACT: MANAGING APPLICATION RISKS AND CONTROLS. Frequently Asked Questions

Risk and Controls 101

1. FPO. Guide to the Sarbanes-Oxley Act: IT Risks and Controls. Second Edition

KANSAS CITY, MISSOURI RESPONSES TO THE FISCAL YEAR 2013 AUDIT MANAGEMENT LETTER

Continuous Controls Monitoring ISACA, Houston Chapter. August 17, 2006

Audit Quality Thematic Review

Connecting the dots: IT to Business

CIIA South West Analytics in Internal Audit - Tackling Fraud

Solihull Metropolitan Borough Council. IT Audit Findings Report September 2015

Audit Phases. Phase 1: Planning and Risk Identification

Auditing Standard 5- Effective and Efficient SOX Compliance

Application Testing: Not Just for IT Auditors. Insert Logo Here

Assessing Credit Risk

How To Audit A Financial Statement

RELEVANT TO FOUNDATION LEVEL PAPER FAU / ACCA QUALIFICATION PAPER F8

C31: Introduction to Application Controls: SAP and JD Edwards Sarah E. Thompson and K. C. Fike, PwC

COSO s 2013 Internal Control Framework in Depth: Implementing the Enhanced Guidance for Internal Control over External Financial Reporting

IT Enabled System : Opportunities & Challenges for Assurance Professionals

S24 - Governance, Risk, and Compliance (GRC) Automation Siamak Razmazma

Reporting on Control Procedures at Outsourcing Entities

Inspection Observations Related to PCAOB "Risk Assessment" Auditing Standards (No. 8 through No.15)

Knowledge Management Series. Internal Audit in ERP Environment

SAP SECURITY CLEARING THE CONFUSION AND TAKING A HOLISTIC APPROACH

auditing in a computer-based

Risks (Audit Risk Formula)

ISACA is responding to the PCAOB questions principally from an information technology (IT) perspective.

Internal Auditing & Controls. Examination phase of the internal audit Module 5. Course Name: Internal Auditing & Controls

Case Study Top-Down, Risk-Based Approach Purchase to Pay Process

J-SOX Compliance Approach Best Practices for Foreign Subsidiaries November 8, 2007

WHITE PAPER. Best Practices for the Use of Data Analysis in Audit. John Verver, CA, CISA, CMC

U S I N G D A T A A N A L Y S I S T O M E E T T H E R E Q U I R E M E N T S O F R I S K B A S E D A U D I T I N G S T A N D A R D S

Understanding ERP Architectures, Security and Risk Brandon Sprankle PwC Partner March 2015

How To Audit A Company

STATEMENT OF AUDITING STANDARDS 300 AUDIT RISK ASSESSMENTS AND ACCOUNTING AND INTERNAL CONTROL SYSTEMS

The Impact of Information Technology on the Audit Process

Auditing Standard ASA 330 The Auditor's Responses to Assessed Risks

IT General Controls Domain COBIT Domain Control Objective Control Activity Test Plan Test of Controls Results

Implementation Tool for Auditors

CHAPTER 8 SPECIALIZED AUDIT TOOLS: SAMPLING AND GENERALIZED AUDIT SOFTWARE

Effectively Assessing IT General Controls

Part II. Audit process by phase 3. Testing and evidence

INTERNATIONAL STANDARD ON AUDITING (UK AND IRELAND) 315

Understanding the Entity and Its Environment and Assessing the Risks of Material Misstatement

Stages of the Audit Process

Communicating Internal Control Related Matters Identified in an Audit

Segregation of Duties

Case Tiger Pride Enterprises

Leverage T echnology: Move Your Business Forward

Using COBiT For Sarbanes Oxley. Japan November 18 th 2006 Gary A Bannister

Navy s Contract/Vendor Pay Process Was Not Auditable

Manager's Guide to TimeIPS

Service Organizations and the Internal Audit function conference Institute of Internal Auditors in Israel

Cycle Counts of Inventory, A Practical Guide

AUDIT EFFICIENCIES: IS YOUR RELIANCE STRATEGY WORKING FOR YOU? Kyleen Wissell, CRISC, PHR, RCC

Internal Controls Best Practices By Jennifer Downs, CPA Benefit Audit Group, LLC

JD Edwards EnterpriseOne Payroll for Canada Rel 9.x

Internal Controls over Financial Reporting. Integrating in Business Processes & Key Lessons learned

Automated Controls Strategy, Implementation & Practical Examples. By Danny Miller, CGEIT, CISA, ITIL

Comparison of ISA 330 with AS-402 Objectives and Requirements Only

Audit Sampling 101. BY: Christopher L. Mitchell, MBA, CIA, CISA, CCSA

Sarbanes-Oxley 404. Sarbanes-Oxley Background. SOX 404 Internal Controls. Goals of Sarbanes-Oxley

Audit Compliance and Internal Audit Analysis for Dynamics

IPPF Practice Guide. Auditing Application Controls

Building an Audit Trail in an Oracle EBS Environment. Presented by: Jeffrey T. Hare, CPA CISA CIA

Webinar: PCAOB Inspections of Small Firm Broker-Dealer Auditors. January 15, 2015

Overall Audit Plan and Audit Program. I. Introduction Chapter is primarily review and integration of the audit framework.

[300] Accounting and internal control systems and audit risk assessments

SOLUTION: AUDIT AND INTERNAL REVIEW, MAY 2014

Navigating the Standards for Information Technology Controls

Change Management Best Practices for ERP Applications, An Internal Auditor's Perspective. Jeffrey T. Hare, CPA CISA CIA ERP Risk Advisors

Learning Objective 1. The Impact of Information Technology on the Audit Process. Describe how IT improves internal control.

Transcription:

Application controls testing in Application controls testing in an integrated audit

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

Types of controls

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

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

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

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

What are application controls?

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

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

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

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

Nature, timing and extent of application controls testing 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 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.

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

Benchmarking of application controls

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

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.

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 controls

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?

Electronic audit evidence (EAE)

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

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 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)

Questions?