PowerPoint Presentation


Published on

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

PowerPoint Presentation

  1. 1. Auditing Standard # 5 and IT Controls Overview of Key Concepts with an Application to IT Controls in Performing an Audit of Internal Control Over Financial Reporting Presented by: Michael Pinna December 14, 2007
  2. 2. Objective <ul><li>To gain an understanding of the concepts in the new Auditing Standard #5 (AS 5) and their relation to IT controls in performing an audit of internal control over financial reporting. </li></ul>
  3. 3. Overview of the New Auditing Standard #5 <ul><li>The new standard supersedes Auditing Standard #2 (AS 2). </li></ul><ul><li>Passed in June/July by the PCAOB and SEC. </li></ul><ul><li>This standard establishes requirements and provides direction that applies when an auditor is engaged to perform an audit of management's assessment of the effectiveness of internal control over financial reporting (&quot;the audit of internal control over financial reporting&quot;) that is integrated with an audit of the financial statements. </li></ul>
  4. 4. Overview of the New Auditing Standard #5 <ul><li>The auditor should use the same suitable, recognized control framework to perform his or her audit of internal control over financial reporting as management uses for its annual evaluation of the effectiveness of the company's internal control over financial reporting. </li></ul><ul><li>Eliminates the requirement to provide an opinion on management’s assessment. </li></ul>
  5. 5. Overview of the New Auditing Standard #5 <ul><li>Areas of Notable Change Between AS 2 and AS 5 include the following items: </li></ul><ul><ul><li>Risk Assessment </li></ul></ul><ul><ul><li>Top-Down Approach </li></ul></ul><ul><ul><li>Removal of Prescriptive Requirements </li></ul></ul><ul><ul><li>Focusing the Audit </li></ul></ul><ul><ul><li>Elimination of Certain Procedures </li></ul></ul><ul><ul><li>Scalability </li></ul></ul>
  6. 6. Role of Risk Assessment in Scaling the Audit <ul><li>Risk assessment underlies the entire audit process described by AS 5, including the determination of: </li></ul><ul><ul><li>Significant accounts and disclosures </li></ul></ul><ul><ul><li>Relevant assertions </li></ul></ul><ul><ul><li>The selection of controls to test </li></ul></ul><ul><ul><li>The determination of the evidence necessary for a given control. </li></ul></ul><ul><li>The complexity of the organization, business unit, or process, will play an important role in the auditor's risk assessment and the determination of the necessary procedures. </li></ul>
  7. 7. Role of Risk Assessment in Scaling the Audit <ul><li>A direct relationship exists between the degree of risk that a material weakness could exist in a particular area of the company's internal control over financial reporting and the amount of audit attention that should be devoted to that area. </li></ul><ul><li>The auditor should focus more of his or her attention on the areas of highest risk. </li></ul><ul><li>It is not necessary to test controls that, even if deficient, would not present a reasonable possibility of material misstatement to the financial statements. </li></ul>
  8. 8. The COSO Model <ul><ul><li>COSO stands for the Committee of Sponsoring Organizations . It is an organization whose mission is to improve financial reporting with a focus on ethics, effective internal controls, and solid corporate governance. </li></ul></ul><ul><ul><li>The organizations that make up COSO are the American Institute of Certified Public Accountants (AICPA), the Institute of Internal Auditors (IIA), Financial Executives International (FEI), Institute of Management Accountants (IMA), and the American Accounting Association (AAA). </li></ul></ul><ul><ul><li>In 1992, the COSO committee published their initial Internal Control – Integrated Framework </li></ul></ul><ul><ul><li>Beginning in 2001, The COSO committee engaged PricewaterhouseCoopers (PwC) to develop the Enterprise Risk Management (ERM) framework using the 1992 model as the basis for their work. </li></ul></ul>
  9. 9. The COSO Model <ul><ul><li>The COSO model for assessing Internal Control has Risk Assessment as one of the “5 Pillars” of COSO. </li></ul></ul>Entity-Level Division Business Unit Subsidiary Monitoring Information & Communication Control Activities Risk Assessment Control Environment Compliance Financial Reporting Operations
  10. 10. The COSO Model <ul><li>The model helps to integrate 3 distinct components – Processes, Entity Levels, and Controls </li></ul><ul><ul><li>Processes are the high level functions most often performed in any organization: </li></ul></ul><ul><ul><ul><li>Operations </li></ul></ul></ul><ul><ul><ul><li>Financial Reporting </li></ul></ul></ul><ul><ul><ul><li>Compliance </li></ul></ul></ul><ul><ul><li>Entity Levels are the strata most often found within organizations: </li></ul></ul><ul><ul><ul><li>Entity/Corporate Level </li></ul></ul></ul><ul><ul><ul><li>Division </li></ul></ul></ul><ul><ul><ul><li>Business Unit </li></ul></ul></ul><ul><ul><ul><li>Subsidiary </li></ul></ul></ul>
  11. 11. The COSO Model <ul><li>The Controls relate to the following: </li></ul><ul><ul><li>1. Control Environment: The control environment sets the tone for the organization. It is the foundation of all other components of internal control, providing discipline and structure. Control environment factors include the integrity, ethical values and competence of the entity’s people, management philosophy and operating style, the way management assigns authority and responsibility, and the attention and direction provided by the board of directors. </li></ul></ul><ul><ul><li>2. Risk Assessment: Risk assessment is the identification and analysis of risks to the achievement of established business objectives and should form a basis to determine how the risks should be managed. As economic, industry, regulatory, and operating conditions change, mechanisms are required to identify and deal with the special risks associated with change. </li></ul></ul>
  12. 12. The COSO Model <ul><li>The Controls relate to the following: </li></ul><ul><ul><li>3. Control Activities: Control activities are the policies and procedures established to ensure management directives are carried out, and ensuring that necessary actions are taken to address risks to achievement of the entity’s business objectives. Control activities occur throughout the organization and include a range of activities such as approvals, authorizations, verifications, reconciliations, reviews of operating performance, security of assets and segregation of duties. </li></ul></ul><ul><ul><li>4. Information and Communication: Information must be identified, captured and communicated timely and in a manner enabling people to fulfill their responsibilities. Reports containing operational, financial and compliance related information should support effective business management, control, and informed business decision-making. Effective communication should occur internally, flowing across organization, and externally, with parties such as customers, suppliers, regulators and shareholders. </li></ul></ul>
  13. 13. The COSO Model <ul><li>The Controls relate to the following: </li></ul><ul><ul><li>5. Monitoring: Internal controls need to be monitored using a process that assesses the quality of their performance over time. Ongoing monitoring must occur in the course of operations through regular management and supervisory activities, and other actions taken by personnel in performing their duties. The scope and frequency of any separate independent evaluations will depend on a risk assessment and the effectiveness of ongoing monitoring procedures. Internal control gaps should be reported upstream, with serious matters reported to senior management and the board of directors. </li></ul></ul>
  14. 14. Why Include IT Controls? <ul><li>IT is an integral part of compliance because there is usually a significant dependency on IT within most organizations: </li></ul><ul><ul><li>High degree of automation in processing day-to-day transactions. </li></ul></ul><ul><ul><li>IT data elements are primary source of information used in decision-making. </li></ul></ul><ul><ul><li>IT availability and integrity are critical to financial statement closing and reporting processes. </li></ul></ul><ul><ul><li>Risk of unwarranted reliance by management on IT systems and controls. </li></ul></ul>
  15. 15. Description of IT Controls <ul><li>Types of IT Controls: </li></ul><ul><ul><li>1. General Computer Controls </li></ul></ul><ul><ul><ul><li>General Computer Controls are the high level controls that typically impact all of the individual applications and data in the technology environment. </li></ul></ul></ul><ul><ul><ul><li>These controls include Application Development, Change Control, Information Security, and Data Center Operations. </li></ul></ul></ul><ul><ul><ul><li>These controls need to be documented, and potentially tested, each year. If there is a solid General Controls environment, it is easier to place more reliance on the Application Level controls. </li></ul></ul></ul><ul><ul><li>2. Application Level Controls </li></ul></ul><ul><ul><ul><li>These are specific controls for the applications in use at the client. An example, is a systematic check to insure that duplicate invoices are not being paid by the AP system. </li></ul></ul></ul><ul><ul><ul><li>The documentation and testing of these controls is based upon discussions with the audit engagement team. You may or may not address application controls each year. </li></ul></ul></ul>
  16. 16. General Computer Controls <ul><li>Application Development </li></ul><ul><ul><li>A System Development Life Cycle (SDLC) exists within organization and is used to guide the development and acquisition processes within the company. </li></ul></ul><ul><ul><li>Project requests and requests for changes are documented and approved by stakeholders. </li></ul></ul><ul><ul><li>Project requests and requests for changes have evidence of requirements definition, retained and approved. </li></ul></ul><ul><ul><li>Project requests and requests for changes have evidence of testing, retained and approved. </li></ul></ul>
  17. 17. General Computer Controls <ul><li>Change Control </li></ul><ul><ul><li>A standard policy/procedure process and/or document exists that details the organization’s methods for applying application, infrastructure, and system software changes. </li></ul></ul><ul><ul><li>A standard change request record/form (electronic or paper) is used to document and track changes and approvals. </li></ul></ul><ul><ul><li>All change requests are approved by the appropriate requesting management, as well as other impacted management (as defined by policies and procedures). </li></ul></ul><ul><ul><li>Emergency changes are tested and approved by authorized management after implementation and follow outlined policies and procedures. </li></ul></ul>
  18. 18. General Computer Controls <ul><li>Information Security </li></ul><ul><ul><li>User administration procedures should be in place to address the requirements for granting, changing, and timely removing access to systems and applications, including remote access capabilities (i.e. the access request process and necessary manager approval). </li></ul></ul><ul><ul><li>Unique user accounts are set up to provide user accountability for use of system resources. All exceptions should be documented and approved. </li></ul></ul><ul><ul><li>Minimum password standards are applied to restrict access (i.e. required password, minimum password length, password change standards, password composition standards, timeout, unsuccessful access attempts). </li></ul></ul><ul><ul><li>Access to the production environment (OS and application programs) is restricted by appropriate facilities (i.e. RACF, Native OS ACLs) and supports segregation of duties (i.e. programmers do not have access to modify code in production libraries, non-administration personal do not have access to root, administrator or RACF SPECIAL attribute). </li></ul></ul>
  19. 19. General Computer Controls <ul><li>Information Security (continued) </li></ul><ul><ul><li>Access to databases is authorized based on job responsibility (i.e. DBA has Oracle administration access) and access to manipulate database files through the OS is restricted by the appropriate facilities (i.e. RACF or native OS ACL). </li></ul></ul><ul><ul><li>Access to sensitive facilities (access to master passwords, powerful utilities (including scheduling packages), and system manager facilities) is granted based on job responsibility. </li></ul></ul><ul><ul><li>Audit logs (e.g. – SU log) are in place to document user access to sensitive or powerful sensitive facilities and reviewed where appropriate. </li></ul></ul><ul><ul><li>Firewall architecture is in place to protect access to internal systems from unauthorized external parties via untrusted networks (i.e. the internet). </li></ul></ul><ul><ul><li>Intrusion Detection Systems are in place and are monitored periodically. </li></ul></ul>
  20. 20. General Computer Controls <ul><li>Data Center Operations </li></ul><ul><ul><li>Management has defined and implemented a problem management process/system to ensure that operational events that are not part of standard operation (i.e. incidents, problems, and errors (e.g., processing abends)) are recorded, analyzed, escalated and resolved in a timely manner. </li></ul></ul><ul><ul><li>System processing jobs and batch feeds are documented in the IT Operations Manual or other equivalent documentation. </li></ul></ul><ul><ul><li>Daily operations checklists are used to assist in monitoring systems processing. </li></ul></ul><ul><ul><li>Critical programs and data are identified by management. Backups of these critical programs and data are scheduled and performed. </li></ul></ul><ul><ul><li>There is an off-site storage process and backups are removed. </li></ul></ul><ul><ul><li>A Disaster Recovery process is in place for all data centers. </li></ul></ul><ul><ul><li>Physical security and environmental control (i.e., raised floor, A/C, fire control system, water sensors, UPS) controls are in place for all data centers. </li></ul></ul>
  21. 21. Application Level Controls <ul><li>Application Controls Include: </li></ul><ul><ul><ul><li>Input Controls </li></ul></ul></ul><ul><ul><ul><ul><li>Edit Checks </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Input File Validation </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Edit/Error Reports </li></ul></ul></ul></ul><ul><ul><ul><li>Processing Controls </li></ul></ul></ul><ul><ul><ul><ul><li>Balancing Controls </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Program Calculations </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Processing Statistics </li></ul></ul></ul></ul><ul><ul><ul><li>Output Controls </li></ul></ul></ul><ul><ul><ul><ul><li>Processing Reports </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Output Files </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Interfaces to Other Systems </li></ul></ul></ul></ul><ul><ul><ul><li>Security Controls </li></ul></ul></ul><ul><ul><ul><ul><li>Application Level Security Controls </li></ul></ul></ul></ul>
  22. 22. The IT Control “Umbrella” General Controls <ul><li>Application Development </li></ul><ul><li>Change Control </li></ul><ul><li>Information Security </li></ul><ul><li>Data Center Operations </li></ul>Application Controls Input Controls Output Controls Processing Controls Security Controls - Edit Checks - Input File Validation - Edit/Error Reports - Balancing Controls - Program Calculations - Processing Statistics - Application Level Security Controls - Processing Reports - Output Files - Interfaces to Other Systems
  23. 23. Key Internal Control Concepts <ul><li>Design Effectiveness </li></ul><ul><ul><li>Are standard IT controls in place at the client location and do they appear to be in operation? </li></ul></ul><ul><ul><li>Are the controls performed by persons possessing the necessary authority and competence to perform the control effectively? </li></ul></ul><ul><ul><li>Procedures performed include a mix of inquiry of personnel, observation of the company’s operations, and inspection of relevant documentation. </li></ul></ul>
  24. 24. Key Internal Control Concepts <ul><li>Design Effectiveness </li></ul><ul><ul><li>Walkthroughs that include the preceding page procedures are sufficient to evaluate the design effectiveness. </li></ul></ul><ul><ul><li>A smaller, less complex company might achieve its control objectives in a different manner from a larger, more complex organization (i.e., less segregation of duties) and my implement alternative controls to achieve its control objectives. In such circumstances, the auditor should evaluate whether those alternative controls are effective. </li></ul></ul>
  25. 25. Key Internal Control Concepts <ul><li>Operating Effectiveness </li></ul><ul><ul><li>Are standard IT controls as documented performing as expected throughout the audit period? </li></ul></ul><ul><ul><li>The amount of testing evidence is directly related to the level of risk assessed for that control. The greater the level of risk – the greater the level of evidence needed to evaluate the operating effectiveness of the control. </li></ul></ul>
  26. 26. Key Internal Control Concepts <ul><li>Operating Effectiveness </li></ul><ul><ul><li>The IT environment has a direct impact on the level of assessed risk since many financial and operational controls are affected by IT controls. </li></ul></ul><ul><ul><li>Procedures performed include a mix of inquiry of personnel, observation of the company’s operations, inspection of relevant documentation, and the re-performance of a control. </li></ul></ul>
  27. 27. Key Internal Control Concepts <ul><li>Inquiry alone is not sufficient to conclude on the operating effectiveness of a control. </li></ul>Re-Performance Inspection of Relevant Documentation Observation Inquiry Reliability of Evidence More Persuasive Less Persuasive
  28. 28. Key Internal Control Concepts <ul><li>Operating Effectiveness </li></ul><ul><ul><li>Testing controls over a greater period of time provides more evidence of the effectiveness of controls than testing over a shorter period of time. </li></ul></ul><ul><ul><li>Testing performed closer to the date of management's assessment provides more evidence than testing performed earlier in the year. The auditor should balance performing the tests of controls closer to the as-of date with the need to test controls over a sufficient period of time to obtain sufficient evidence of operating effectiveness. </li></ul></ul>
  29. 29. Key Internal Control Concepts <ul><li>Operating Effectiveness </li></ul><ul><ul><li>If a new control is implemented in the testing period, and sufficient time exists to test the new control, then the auditor may elect not to test the old/superseded control. </li></ul></ul><ul><ul><li>The more extensively a control is tested, the greater the evidence obtained from that test. </li></ul></ul><ul><ul><li>When the auditor reports on the effectiveness of controls as of a specific date and obtains evidence about the operating effectiveness of controls at an interim date, the auditor should determine what additional evidence concerning the operation of the controls for the remaining period is necessary. </li></ul></ul>
  30. 30. Evaluating Control Deficiencies <ul><li>The auditor must evaluate the severity of each control deficiency that comes to his or her attention to determine whether the deficiencies, individually or in combination, are material weaknesses as of the date of management's assessment. </li></ul><ul><li>In planning and performing the audit, however, the auditor is not required to search for deficiencies that, individually or in combination, are less severe than a material weakness. </li></ul><ul><li>The severity of a deficiency is based on the “reasonable possibility” concept vs. the magnitude of the potential misstatement. </li></ul>
  31. 31. Evaluating Control Deficiencies <ul><li>A new definition is presented for a material weakness (MW) to align with SEC guidance. </li></ul><ul><li>Revises the definition of a significant deficiency (SD) to align with the definition the SEC has proposed. </li></ul><ul><li>AS 5 encourages the use of auditor judgment in evaluating MWs and SDs. The goal is to move away from “prescribed” MWs and SDs based on the standard. </li></ul>
  32. 32. Benchmarking of Automated Controls <ul><li>Entirely automated application controls are generally not subject to breakdowns due to human failure. This feature allows the auditor to use a &quot;benchmarking&quot; strategy. </li></ul><ul><li>If general controls are effective and continue to be tested, and if the auditor verifies that the automated application control has not changed since the auditor established a baseline (i.e., last tested the application control), the auditor may conclude that the automated application control continues to be effective without repeating the prior year's specific tests of the operation of the automated application control. </li></ul>
  33. 33. Benchmarking of Automated Controls <ul><li>The nature and extent of the evidence that the auditor should obtain to verify that the control has not changed may vary depending on the circumstances, including depending on the strength of the company's program change controls. </li></ul><ul><li>Certain automated controls may be dependent on other automated controls in order to function properly. Therefore, the auditor may need to evaluate the entire process and not just an isolated control. </li></ul>
  34. 34. Benchmarking of Automated Controls <ul><li>To determine whether to use a benchmarking strategy, the auditor should assess the following risk factors: </li></ul><ul><ul><li>The extent to which the application control can be matched to a defined program/module within an application. </li></ul></ul><ul><ul><li>The extent to which the application is stable (i.e., there are few changes from period to period). </li></ul></ul><ul><ul><li>The availability and reliability of information on the nature and timing of program changes. </li></ul></ul><ul><ul><li>The program change process – including the lockdown of the production libraries/directories. </li></ul></ul><ul><li>As these factors indicate lower risk, the control being evaluated might be well-suited for benchmarking. </li></ul>
  35. 35. Benchmarking of Automated Controls <ul><li>Benchmarking automated application controls can be especially effective for companies using purchased software when the possibility of program changes is remote (e.g., when the vendor does not allow access or modification to the source code). </li></ul><ul><li>After a period of time, the length of which depends upon the circumstances, the baseline of the operation of an automated application control should be reestablished. </li></ul>
  36. 36. Questions ? <ul><li>??????????????? </li></ul>
  37. 37. Contact Information Michael Pinna Director - IT Risk Services Weiser LLP (732) 475-2198 mpinna@weiserllp.com
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.