GAIT Approach to Regulatory Compliance Edward L. Hill Managing Director  Protiviti Jay R. Taylor, CIA, CFE, CISA General D...
Today’s  Agenda <ul><li>The Who, What, and Why of GAIT </li></ul><ul><ul><li>GAIT Evolution, Principles and Methodology </...
What is  GAIT? <ul><li>G uide to the  A ssessment of  IT   General Controls Scope Based on Risk </li></ul><ul><ul><li>A se...
Why Was  GAIT Formed? <ul><li>Lack of established guidance (inconsistency and subjectivity, reliance on checklists, etc.) ...
Survey on  ITGC Sox Scoping <ul><li>IIA January, 2007, survey: </li></ul><ul><li>inefficiencies exist in scoping ITGC </li...
Need  for Guidance? <ul><li>More than three-quarters felt guidance would be of high value </li></ul>Yes - 77%
Who  Developed GAIT for SOX scoping? <ul><li>Core Team </li></ul><ul><li>Ed Hill, Protiviti </li></ul><ul><li>Gene Kim, Tr...
Who  Helped with GAIT for SOX scoping? <ul><li>Advisory Board </li></ul><ul><li>CPA Firms – Big Four, Mid-sized Firms </li...
What  is GAIT for SOX scoping?   <ul><li>GAIT is a reasoned thinking process that  continues  the top-down and risk-based ...
How  Does GAIT for SOX Scoping Work? <ul><li>The GAIT document has two main parts </li></ul><ul><ul><li>The Four Principle...
Top-Down Risk-Based
Overall  GAIT Scoping <ul><li>Significant accounts </li></ul><ul><ul><li>Business processes </li></ul></ul><ul><ul><ul><li...
IT Risk Assessment  and Scoping <ul><li>Significant accounts </li></ul><ul><ul><li>Business processes </li></ul></ul><ul><...
<ul><li>The identification of risks and related controls in IT business processes should be a continuation of the top-down...
<ul><li>The IT general control process risks that need to be identified are those that affect critical IT functionality in...
Financially Significant-  Definition <ul><li>Application: contains functionality relied upon to assure the integrity of th...
<ul><li>The IT general control process risks that need to be identified exist in processes and at various IT layers: appli...
<ul><li>Risks in IT general control processes are mitigated by the achievement of IT control objectives, not individual co...
<ul><li>. . . guides you by asking  </li></ul><ul><li>three questions: </li></ul>The  GAIT Methodology
<ul><li>What  IT functionality in the financially significant applications   is critical  to the proper operation of  the ...
<ul><li>For each IT process at each layer in the stack, is there a  reasonable possibility that a process failure would ca...
<ul><li>If such IT business process risks exist, what are the  relevant IT control objectives? </li></ul>The  GAIT Methodo...
<ul><li>The Next GAIT </li></ul><ul><li>is GAIT </li></ul><ul><li>for Deficiency Evaluation </li></ul><ul><li>and Conclusi...
Background for GAIT for Deficiency Evaluations <ul><li>2004: Framework by CPA firms </li></ul><ul><li>2007: Revised defini...
Principles <ul><li>In order to assess ITGC deficiencies, it is necessary to understand the ‘reliance chain’ between the fi...
Indirect Relationship
Reliance Chain
Principles <ul><li>In order for there to be a material weakness, two tests have to be met: (a) likelihood and (b) impact (...
Principles <ul><li>All ITGC control objectives that are not achieved and relate to the same key automated controls, key re...
Assessment Steps
Assessment Steps
Assessment Steps
Assessment Steps
Closing  Summary <ul><li>Assess ITGC deficiencies based on the risk to critical functionality, and the risk of that failin...
GAIT for IT and Business Risk Edward Hill, CIA Managing Director Protiviti
GAIT for IT and Business Risk-   What it is meant to be <ul><li>Methodology for identifying  all  the key controls critica...
Who should use this guidance? <ul><li>Primarily for internal auditing practitioners: </li></ul><ul><ul><li>Those who run s...
Principles <ul><li>Principle 1 :  The failure of technology is only a risk that needs to be assessed, managed, and audited...
Principles <ul><li>Principle 3 :  Business risks are mitigated by a combination of manual and automated key controls.  To ...
Sub Principles- identification of key ITGC’s   <ul><li>Principle 4a:  The IT general control process risks that need to be...
Key control types: <ul><li>Manual controls (e.g., the performance of a physical inventory) </li></ul><ul><li>Fully automat...
TOP-DOWN METHODOLOGY   <ul><li>Identify the business objectives for which the controls are to be assessed </li></ul><ul><l...
TOP-DOWN METHODOLOGY   <ul><li>Identify the critical IT functionality relied upon, from among the key business controls </...
TOP-DOWN METHODOLOGY   <ul><li>Identify ITGC process risks and related control objectives  </li></ul><ul><li>Identify the ...
Step 7-  Perform a “reasonable person,” holistic review of all the key controls identified
Step 8.  Determine the scope of the review <ul><li>A complete business audit (some might consider this an ‘integrated’ aud...
Step 8.  Determine the scope of the review <ul><li>An audit that is limited in scope to only selected key controls </li></...
Closing  Summary <ul><li>GAIT for IT and Business Risk addresses how IT risk and controls should be addressed in considera...
Case Study Audit of Environmental Compliance Management Process Using GAIT Jay R. Taylor
1.  Business Objectives <ul><li>Business Process:  Manage Environmental Legal Compliance (e.g., the production of required...
Business Risks  <ul><ul><li>Key Business Risk: Under-reporting releases of hazardous chemicals and emissions </li></ul></u...
Process Overview for the Environmental Management Process (EMP) Data Acquisition and Validation Report Development and Rev...
So … we only have a certain number of audit hours …  What is critical to review?  Why??
2.  Key Controls in the Business Process to Achieve Business Objectives A = Timeliness B =  Completeness C = Accuracy Obje...
3. Critical IT Functionality Relied Upon from Among the Key Business Controls Key Controls Related IT Functionality 1. Cal...
4. The Applications Where IT General Controls Need to be Tested <ul><li>“ Ops Environmental System” or OES </li></ul><ul><...
5. IT General Control Process Risks and Related Control Objectives Key Controls Related Risks Control Objectives 1. Calend...
5. IT General Control Process Risks and Related Control Objectives, Continued Key Controls Related Risks Control Objective...
6. IT General Controls to Test, That Meet the Control Objectives Control Objectives IT General Controls (Examples) <ul><li...
7.  Perform a “reasonable person,” holistic review of all the key controls identified <ul><li>COSO Categories : </li></ul>...
8. Scope of the Review – Integrated Audit – Coverage of All Business Risks <ul><li>Now that the detailed scoping for this ...
Scope Change Needed <ul><li>What if some plants may not have migrated to the new OES system? </li></ul><ul><ul><li>Continu...
Conclusions and Lessons Learned <ul><li>GAIT useful for scoping SOX 404 and any IT audit work </li></ul><ul><li>GAIT resul...
Conclusions and Lessons Learned, Continued <ul><li>Improved audit comment wording helps to connect to things management ca...
Conclusions and Lessons Learned, Continued <ul><li>Linking finding to business risk makes it real: </li></ul><ul><ul><ul><...
More Information . . . <ul><li>GAIT Resources www.theiia.org   </li></ul><ul><li>Questions? Ask Dr. GAIT [email_address] <...
Thank you!
Upcoming SlideShare
Loading in …5
×

Iiaic08 power point cs2-3_track_regulatory session v3

2,145 views

Published on

GAIT-R framework, extending beyond SOX-404 to any COSO objective

Presented by Jay Taylor and Ed Hill at 2008 Institute of Internal Auditors Internal Conference

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,145
On SlideShare
0
From Embeds
0
Number of Embeds
564
Actions
Shares
0
Downloads
29
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Steve During today’s presentation, we will discuss: What GAIT is. Why GAIT was established. Who developed GAIT GAIT Principles &amp; Methodology Tips &amp; Practical Techniques And getting started with GAIT And now, to kick off today’s presentation, I’d like to begin with an overview of what GAIT is and the problems that GAIT is designed to alleviate . . .
  • Steve A January, 2007, survey* indicated inefficiencies exist in scoping ITGC, costs are too high for many organizations, and guidance would be highly valuable. * 533 respondents, primarily internal auditors and IT Audit managers.
  • Steve More than three-quarters felt guidance would be of high value. And now, Steve, please tell our viewers about the GAIT team.
  • Steve In early 2005, the IIA Technology Committee created the GAIT task force, which has held five GAIT Summits since July 2005 The GAIT Summits assembled key stakeholders from internal auditing, management, external auditing, and federal regulators GAIT Team’s Vision and Goals To develop in 2006 a set of widely-used and widely-accepted guiding principles, tools, methodologies and scenarios that can be used by management and auditors to properly scope IT general controls work for financial reporting and SOX-404. To develop a short- and medium-term roadmap that moves the GAIT Principles from new guidance to great advice to generally accepted. To develop a long-term roadmap that expands the GAIT Principles from internal control objectives for just financial reporting, to one that encompasses compliance with laws and regulations, operating effectiveness, etc.
  • The GAIT methodology examines each financially significant application and determines whether failures in the IT business processes at each layer in the stack represent a likely threat to the consistent operation of the application’s critical functionality. If a failure is likely, GAIT identifies the IT business process risks in detail and the related ITGC control objectives that, when achieved, mitigate the risks. COBIT and other methodologies can identify the key controls to address the ITGC control objectives. In short, the GAIT methodology guides you through asking three questions in sequence: What IT functionality in the financially significant applications is critical to the proper operation of the business process key controls that prevent/detect material misstatement (i.e., what is the critical IT functionality)? For each IT process at each layer in the stack, is there a reasonable likelihood that a process failure would cause the critical functionality to fail —indirectly representing a risk of material misstatement (i.e., if that process failed at that layer, what effect would there be on the critical functionality? Would it cause the functionality to fail such that there would be a reasonably likely risk of material misstatement)? If such IT business process risks exist, what are the relevant IT control objectives (i.e., what IT control objectives need to be achieved to provide assurance over the critical functionality)?
  • Steve During today’s presentation, we will discuss: What GAIT is. Why GAIT was established. Who developed GAIT GAIT Principles &amp; Methodology Tips &amp; Practical Techniques And getting started with GAIT And now, to kick off today’s presentation, I’d like to begin with an overview of what GAIT is and the problems that GAIT is designed to alleviate . . .
  • Iiaic08 power point cs2-3_track_regulatory session v3

    1. 1. GAIT Approach to Regulatory Compliance Edward L. Hill Managing Director Protiviti Jay R. Taylor, CIA, CFE, CISA General Director of Audit General Motors Corporation
    2. 2. Today’s Agenda <ul><li>The Who, What, and Why of GAIT </li></ul><ul><ul><li>GAIT Evolution, Principles and Methodology </li></ul></ul><ul><ul><li>GAIT for SOX IT Scoping </li></ul></ul><ul><ul><li>GAIT Deficiency Evaluation </li></ul></ul><ul><ul><li>GAIT- for IT and Business Risks </li></ul></ul><ul><li>Applying GAIT to an Environmental Audit </li></ul><ul><li>Lessons Learned </li></ul><ul><li>Conclusion </li></ul>
    3. 3. What is GAIT? <ul><li>G uide to the A ssessment of IT General Controls Scope Based on Risk </li></ul><ul><ul><li>A series of principles and methodologies for top-down, risk-based scoping of IT general controls </li></ul></ul>
    4. 4. Why Was GAIT Formed? <ul><li>Lack of established guidance (inconsistency and subjectivity, reliance on checklists, etc.) </li></ul><ul><li>Originally Generally Applied IT Principles </li></ul><ul><li>Most pressing need was rationalization of SOX practices- so the first GAIT addressed SOX compliance </li></ul><ul><li>Significant compliance and audit costs </li></ul><ul><li>Need for better overall scoping frameworks </li></ul>
    5. 5. Survey on ITGC Sox Scoping <ul><li>IIA January, 2007, survey: </li></ul><ul><li>inefficiencies exist in scoping ITGC </li></ul><ul><li>costs are too high </li></ul><ul><li>guidance would be highly valuable </li></ul>
    6. 6. Need for Guidance? <ul><li>More than three-quarters felt guidance would be of high value </li></ul>Yes - 77%
    7. 7. Who Developed GAIT for SOX scoping? <ul><li>Core Team </li></ul><ul><li>Ed Hill, Protiviti </li></ul><ul><li>Gene Kim, Tripwire </li></ul><ul><li>Steve Mar, Microsoft </li></ul><ul><li>Norman Marks, Business Objects </li></ul><ul><li>Heriot Prentice, The IIA </li></ul><ul><li>Fawn Weaver, Intel </li></ul>
    8. 8. Who Helped with GAIT for SOX scoping? <ul><li>Advisory Board </li></ul><ul><li>CPA Firms – Big Four, Mid-sized Firms </li></ul><ul><li>SEC Registrants </li></ul><ul><li>Regulators </li></ul>
    9. 9. What is GAIT for SOX scoping? <ul><li>GAIT is a reasoned thinking process that continues the top-down and risk-based approach in AS/5 to assess risk in ITGC </li></ul><ul><li>It helps identify risk in IT processes that could affect critical functionality needed to prevent/detect material errors </li></ul><ul><li>Control objectives are identified in GAIT, but not specific key controls </li></ul>
    10. 10. How Does GAIT for SOX Scoping Work? <ul><li>The GAIT document has two main parts </li></ul><ul><ul><li>The Four Principles </li></ul></ul><ul><ul><li>Methodology for GAIT implementation </li></ul></ul><ul><li>Overall theory </li></ul><ul><li>Practical Approach </li></ul>
    11. 11. Top-Down Risk-Based
    12. 12. Overall GAIT Scoping <ul><li>Significant accounts </li></ul><ul><ul><li>Business processes </li></ul></ul><ul><ul><ul><li>Business controls </li></ul></ul></ul><ul><ul><ul><ul><li>Applications </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>General Controls </li></ul></ul></ul></ul></ul>RISK of material misstatement/fraud to financial statements & disclosures Scope according to RISK of material misstatement/fraud.
    13. 13. IT Risk Assessment and Scoping <ul><li>Significant accounts </li></ul><ul><ul><li>Business processes </li></ul></ul><ul><ul><ul><li>Business controls </li></ul></ul></ul><ul><ul><ul><ul><li>Applications </li></ul></ul></ul></ul>STEP 1 : validate understanding STEP 2 : perform risk assessment at each layer STEP 3 : Conclude: is it REASONABLY POSSIBLE a failure in this IT Process area could impact application controls & result in a material misstatement? Risk is not eliminated; is it reduced to a REASONABLE level. <ul><ul><ul><ul><ul><li>IT Process Controls: </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Change Mgt, Operations, Security </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Application </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Database </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Operating System </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Network </li></ul></ul></ul></ul></ul>
    14. 14. <ul><li>The identification of risks and related controls in IT business processes should be a continuation of the top-down and risk-based approach used to identify significant accounts, risks to those accounts, and key controls in the business processes. </li></ul>GAIT Principle 1
    15. 15. <ul><li>The IT general control process risks that need to be identified are those that affect critical IT functionality in financially significant applications and related data . </li></ul>GAIT Principle 2
    16. 16. Financially Significant- Definition <ul><li>Application: contains functionality relied upon to assure the integrity of the financial reporting process. </li></ul><ul><ul><li>Should that functionality not function consistently and correctly, there is at least a reasonable possibility of a material misstatement that would not be prevented or detected. </li></ul></ul><ul><li>Data: data that, if affected by unauthorized change that bypasses normal application controls (i.e., as a result of an ITGC failure), is at least reasonably likely to result in a material misstatement that would not be prevented or detected. </li></ul>
    17. 17. <ul><li>The IT general control process risks that need to be identified exist in processes and at various IT layers: application program code, databases, operating systems, and network. </li></ul>GAIT Principle 3
    18. 18. <ul><li>Risks in IT general control processes are mitigated by the achievement of IT control objectives, not individual controls. </li></ul>GAIT Principle 4
    19. 19. <ul><li>. . . guides you by asking </li></ul><ul><li>three questions: </li></ul>The GAIT Methodology
    20. 20. <ul><li>What IT functionality in the financially significant applications is critical to the proper operation of the business process key controls that prevent/detect material misstatement? </li></ul>The GAIT Methodology
    21. 21. <ul><li>For each IT process at each layer in the stack, is there a reasonable possibility that a process failure would cause the critical functionality to fail — indirectly representing a risk of material misstatement? </li></ul>The GAIT Methodology
    22. 22. <ul><li>If such IT business process risks exist, what are the relevant IT control objectives? </li></ul>The GAIT Methodology
    23. 23. <ul><li>The Next GAIT </li></ul><ul><li>is GAIT </li></ul><ul><li>for Deficiency Evaluation </li></ul><ul><li>and Conclusions </li></ul>© 2007 Protiviti Inc. All Rights Reserved. This document is for your company’s internal use only and may not be distributed to any other third party.
    24. 24. Background for GAIT for Deficiency Evaluations <ul><li>2004: Framework by CPA firms </li></ul><ul><li>2007: Revised definitions of material weakness and significant deficiency </li></ul><ul><li>2007: Original GAIT published: Methodology for defining Sarbanes-Oxley Section 404 ITGC scope based on risk </li></ul><ul><li>2008: GAIT for ITGC Deficiency Evaluations published </li></ul>
    25. 25. Principles <ul><li>In order to assess ITGC deficiencies, it is necessary to understand the ‘reliance chain’ between the financial statements and the ITGC key controls that have failed. </li></ul><ul><li>Indirect relationship between financial statement risk and ITGC key controls </li></ul>
    26. 26. Indirect Relationship
    27. 27. Reliance Chain
    28. 28. Principles <ul><li>In order for there to be a material weakness, two tests have to be met: (a) likelihood and (b) impact (the potential misstatement of the financial statements). </li></ul><ul><li>Because an ITGC deficiency does not directly affect the financial statements, the assessment is similarly not direct. The assessment is in stages or steps, and the likelihood and impact tests are applied across the combination of the steps </li></ul><ul><li>All ITGC deficiencies that relate to the same ITGC control objective should be assessed as a group </li></ul>
    29. 29. Principles <ul><li>All ITGC control objectives that are not achieved and relate to the same key automated controls, key reports, or other critical functionality should be assessed as a group </li></ul><ul><li>The principle of aggregation requires that control deficiencies of all types — including manual and automated control deficiencies relating to the same significant account or disclosure — be considered as a group </li></ul>
    30. 30. Assessment Steps
    31. 31. Assessment Steps
    32. 32. Assessment Steps
    33. 33. Assessment Steps
    34. 34. Closing Summary <ul><li>Assess ITGC deficiencies based on the risk to critical functionality, and the risk of that failing and leading to a material misstatement </li></ul><ul><li>Consider whether the failure is at least reasonably likely to have such an effect </li></ul><ul><li>Use common sense, grounded in reality </li></ul>
    35. 35. GAIT for IT and Business Risk Edward Hill, CIA Managing Director Protiviti
    36. 36. GAIT for IT and Business Risk- What it is meant to be <ul><li>Methodology for identifying all the key controls critical to achieving business goals and objectives </li></ul><ul><li>Identifies the critical aspects of information technology essential to the management and mitigation of business risk </li></ul><ul><li>The critical IT functionalities and the risks to them should be considered when planning audit work. </li></ul>
    37. 37. Who should use this guidance? <ul><li>Primarily for internal auditing practitioners: </li></ul><ul><ul><li>Those who run such functions within organizations (Chief Audit Executives, or “CAE’s”) or leaders of internal audit service providers, and </li></ul></ul><ul><ul><li>Those who are responsible specifically for the auditing of information technology (IT auditors) </li></ul></ul><ul><ul><li>Also used by IT governance and security managers, or those who are charged with designing and managing information technology risks within their organizations. </li></ul></ul>
    38. 38. Principles <ul><li>Principle 1 : The failure of technology is only a risk that needs to be assessed, managed, and audited if it represents a risk to the business. </li></ul><ul><li>Principle 2 : Key controls should be identified as the result of a top-down assessment of business risk, risk tolerance, and the controls- including automated controls and IT general controls- required to manage or mitigate business risk </li></ul>
    39. 39. Principles <ul><li>Principle 3 : Business risks are mitigated by a combination of manual and automated key controls. To assess the system of internal control to manage or mitigate business risks, key automated controls need to be assessed. </li></ul><ul><li>Principle 4 : IT general controls may be relied upon to provide assurance of the continued and proper operation of automated key controls. </li></ul>
    40. 40. Sub Principles- identification of key ITGC’s <ul><li>Principle 4a: The IT general control process risks that need to be identified are those that affect critical IT functionality in significant applications and related data. </li></ul><ul><li>Principle 4b: The IT general control process risks that need to be identified exist in processes and at various IT layers: the application program code, databases, operating systems, and network. </li></ul><ul><li>Principle 4c: Risks in IT general control processes are mitigated by the achievement of IT control objectives, not individual controls. </li></ul>
    41. 41. Key control types: <ul><li>Manual controls (e.g., the performance of a physical inventory) </li></ul><ul><li>Fully automated controls (e.g., matching or updating accounts in the general ledger) </li></ul><ul><li>Partly automated, or “ hybrid controls ” , where an otherwise manual control relies on application functionality. </li></ul><ul><ul><li>If an error in that functionality would not be detected, the entire control would be ineffective. </li></ul></ul>
    42. 42. TOP-DOWN METHODOLOGY <ul><li>Identify the business objectives for which the controls are to be assessed </li></ul><ul><li>Identify the key controls within business processes required to provide reasonable assurance that the business objectives will be achieved </li></ul>
    43. 43. TOP-DOWN METHODOLOGY <ul><li>Identify the critical IT functionality relied upon, from among the key business controls </li></ul><ul><li>Identify the [significant] applications where ITGC need to be tested. </li></ul>
    44. 44. TOP-DOWN METHODOLOGY <ul><li>Identify ITGC process risks and related control objectives </li></ul><ul><li>Identify the ITGC to test that meet control objectives </li></ul>
    45. 45. Step 7- Perform a “reasonable person,” holistic review of all the key controls identified
    46. 46. Step 8. Determine the scope of the review <ul><li>A complete business audit (some might consider this an ‘integrated’ audit) of all the risks </li></ul><ul><ul><li>The auditor should decide whether to perform the assessment in a single project, or split among multiple projects that may be performed at different times </li></ul></ul><ul><ul><li>If the assessment will be split among multiple projects, the auditor should determine how the combined assessment will be made and reported, as well as how the results of individual projects will be assessed and reported </li></ul></ul>
    47. 47. Step 8. Determine the scope of the review <ul><li>An audit that is limited in scope to only selected key controls </li></ul><ul><ul><li>The limited scope should be clearly identified and communicated both prior to work starting and also in the audit report </li></ul></ul><ul><ul><li>Keep in mind that the assessment of any control deficiencies may be more difficult without understanding the effectiveness of all related controls, and whether the impact of any deficiencies may be mitigated by other key controls that were not assessed </li></ul></ul><ul><li>A consulting project, rather than an assurance project, designed to add value by improving the effectiveness of the system of internal control </li></ul>
    48. 48. Closing Summary <ul><li>GAIT for IT and Business Risk addresses how IT risk and controls should be addressed in consideration of the overall business use of technology </li></ul><ul><li>There is a top-down approach to determining what technology risks and controls are important to the achievement of business goals and objectives </li></ul><ul><li>Technology risks only matter when viewed in the broader business risk context </li></ul>
    49. 49. Case Study Audit of Environmental Compliance Management Process Using GAIT Jay R. Taylor
    50. 50. 1. Business Objectives <ul><li>Business Process: Manage Environmental Legal Compliance (e.g., the production of required federal and state governmental reporting for manufacturing facilities) </li></ul><ul><ul><li>Business Objective: File complete and accurate annual reports required under the U.S. Superfund Amendment Reauthorization Act (SARA) Title III, Section 313 and 40 CFR 370/372 </li></ul></ul><ul><ul><li>COSO Objective: Manage Regulatory / Legal Risk </li></ul></ul>
    51. 51. Business Risks <ul><ul><li>Key Business Risk: Under-reporting releases of hazardous chemicals and emissions </li></ul></ul><ul><ul><ul><li>Fines and penalties ranging up to $37,000 per incident, per day </li></ul></ul></ul><ul><ul><li>Other Risks: </li></ul></ul><ul><ul><ul><li>Failure to comply with laws and regulations </li></ul></ul></ul><ul><ul><ul><li>Access to information may not be based on business need </li></ul></ul></ul><ul><ul><ul><li>Reputation risk / negative media exposure </li></ul></ul></ul><ul><ul><ul><li>3 rd party risk – relying on vendor for maintaining and hosting IT system </li></ul></ul></ul>
    52. 52. Process Overview for the Environmental Management Process (EMP) Data Acquisition and Validation Report Development and Review Project Completion File Reports <ul><li>Flowcharted the EMP </li></ul><ul><ul><li>EMP includes 13 distinct steps </li></ul></ul><ul><li>System supporting the process is called “Ops Environmental System” or OES </li></ul><ul><ul><li>Collect, calculate and analyze purchases and uses of hazardous chemicals </li></ul></ul><ul><ul><li>Prepare and submit reports in compliance with U.S. and state regulations </li></ul></ul><ul><li>OES hosted by 3 rd party provider (called Trusty Tech or “TT”) but owned by company </li></ul>
    53. 53. So … we only have a certain number of audit hours … What is critical to review? Why??
    54. 54. 2. Key Controls in the Business Process to Achieve Business Objectives A = Timeliness B = Completeness C = Accuracy Objectives Key Controls A B C 1. Calendar-based reminders to users prompting input of critical data (automated) X X 2. Entry and edit of chemical purchases, usages, losses, releases, etc. (hybrid) X 3. Comparison of current results (post-calculation) to previous results (automated) X X 4. Final review of reports including support data (hybrid – heavy dependence) (note: “precision”) X X 5. e-Filing of regulatory reports X
    55. 55. 3. Critical IT Functionality Relied Upon from Among the Key Business Controls Key Controls Related IT Functionality 1. Calendar reminders to users (automated) Programmed routine including user notification 2. Entry and edit of chemical purchases (hybrid) Programmed edits against tables (range check; chemical types; etc.) 3. Comparison of current results to previous results (automated) Calculate quantities not accounted for, and compare to thresholds and priors 4. Final review of report including support (hybrid) Select transactions, format, and print user reports 5. e-Filing of regulatory reports Select, format, & transmit
    56. 56. 4. The Applications Where IT General Controls Need to be Tested <ul><li>“ Ops Environmental System” or OES </li></ul><ul><li>Hosted and operated by Trusty Tech Co. on our behalf </li></ul><ul><ul><li>Desire to audit may result in “push back” by TT to internal auditors </li></ul></ul><ul><ul><ul><li>Contractual terms and conditions; SLAs </li></ul></ul></ul><ul><ul><ul><li>Consideration of SAS-70s </li></ul></ul></ul><ul><li>Out of Scope for Planning (will revisit this decision later in the process) : </li></ul><ul><ul><li>Purchasing system – reviewed separately w/Dept. audit </li></ul></ul><ul><ul><li>Material receiving system – reviewed separately in plants </li></ul></ul><ul><ul><li>Excel spreadsheets (accumulate purchases) – minor role </li></ul></ul>
    57. 57. 5. IT General Control Process Risks and Related Control Objectives Key Controls Related Risks Control Objectives 1. Calendar reminders <ul><li>Overdue tasks not flagged or referred to users for follow-up </li></ul><ul><li>Controls ensure that all tasks have assigned due dates and users </li></ul>2. Entry/edit of purchases, receipts, etc. <ul><li>Incorrect quantities, chemical types, etc. entered by users </li></ul><ul><li>Controls ensure that data entered conforms to business rules (e.g. format); errors are rejected </li></ul>3. Comparison of results (period to period; similar facilities; threshold comparisons, etc.) <ul><li>Calculated results may be out of line but not identified; regulatory thresholds may be inaccurate for comparison purposes </li></ul><ul><li>Controls ensure calculations & transaction summarization is performed accurately and results appropriately displayed to users for review </li></ul>
    58. 58. 5. IT General Control Process Risks and Related Control Objectives, Continued Key Controls Related Risks Control Objectives 4. Final review of report <ul><li>Reports produced by OES system may contain calculation errors or other inaccuracies </li></ul><ul><li>Controls ensure that transactions are summarized, and calculations are performed accurately and consistently </li></ul>5. e-Filing of reports <ul><li>Reports may be transmitted using wrong template (federal, state); may be transmitted late; may not identify missing delivery acknowledgements </li></ul><ul><li>Controls ensure that proper template is selected and used </li></ul><ul><li>Controls ensure report delivery is timely and evidence of receipt is obtained from regulator </li></ul>
    59. 59. 6. IT General Controls to Test, That Meet the Control Objectives Control Objectives IT General Controls (Examples) <ul><li>Controls ensure that all tasks have assigned due dates and users </li></ul><ul><li>Application and Database security – table update functionality </li></ul><ul><li>Change control – application code </li></ul><ul><li>Controls ensure that data entered conforms to business rules (e.g. format); errors are rejected </li></ul><ul><li>Application and Database security – input transactions </li></ul><ul><li>Change control – application code – edit rules and error identification </li></ul><ul><li>Controls ensure calculations and summarizations are correctly performed and results appropriately displayed to users for review </li></ul><ul><li>Change control – application code – critical calculations and report format </li></ul><ul><li>Application, Database & OS security – display and modify results </li></ul>
    60. 60. 7. Perform a “reasonable person,” holistic review of all the key controls identified <ul><li>COSO Categories : </li></ul><ul><li>Control Environment </li></ul><ul><li>Risk Assessment </li></ul><ul><li>Control Activities </li></ul><ul><li>Monitoring </li></ul><ul><li>Information and Communication </li></ul>Q: Extremely good or bad?? Impact the audit plan?
    61. 61. 8. Scope of the Review – Integrated Audit – Coverage of All Business Risks <ul><li>Now that the detailed scoping for this project is finished …. </li></ul><ul><li>Am I covering each of the business risks? </li></ul><ul><li>Do I need to reference and rely upon something that is out of scope, so management understands what I did NOT do? </li></ul><ul><ul><li>Example: Purchasing system covered in another audit </li></ul></ul><ul><li>Am I planning to rely on the IT general controls? </li></ul><ul><ul><li>Would a reasonable person with this same information come to the same conclusions? </li></ul></ul><ul><ul><li>Can I really conclude the way I did? </li></ul></ul>
    62. 62. Scope Change Needed <ul><li>What if some plants may not have migrated to the new OES system? </li></ul><ul><ul><li>Continuing to operate on spreadsheets </li></ul></ul><ul><ul><li>Much higher risk of error in this environment </li></ul></ul><ul><ul><li>Complex calculations and logic require explanation and documentation </li></ul></ul><ul><ul><li>Change control and security needed </li></ul></ul><ul><li>Must decide: expand the scope, or exclude from scope and explain in final audit report </li></ul><ul><ul><li>Impact on assurance I can give? </li></ul></ul>
    63. 63. Conclusions and Lessons Learned <ul><li>GAIT useful for scoping SOX 404 and any IT audit work </li></ul><ul><li>GAIT results in the ability to do less test work overall </li></ul><ul><ul><li>However, the work that is completed is clearly targeted to cover the key business risks </li></ul></ul><ul><ul><li>Now, let’s look at how to write up our findings ….. </li></ul></ul>
    64. 64. Conclusions and Lessons Learned, Continued <ul><li>Improved audit comment wording helps to connect to things management cares about: </li></ul><ul><ul><ul><li>“ We noted poor change control procedures and were unable to obtain comfort that all changes were authorized and tested as required” </li></ul></ul></ul><ul><ul><ul><li>-- vs. -- </li></ul></ul></ul><ul><ul><ul><li>“ Poor change control practices introduced the risk of unauthorized or untested changes to key data such as annual threshold amounts for toxic chemical releases. Given the level of precision applied to reviewing the final report downstream, it is unlikely management would detect such errors. Our testing disclosed numerous “break/fix” changes had been made to code or data without supervisory review and approval or notifying the users.” </li></ul></ul></ul>
    65. 65. Conclusions and Lessons Learned, Continued <ul><li>Linking finding to business risk makes it real: </li></ul><ul><ul><ul><li>“ We noted that system edits did not ensure user input was in the proper format or that unallowed materials were rejected from further processing” </li></ul></ul></ul><ul><ul><ul><li>-- vs. -- </li></ul></ul></ul><ul><ul><ul><li>“ Edit routines for user input were not properly designed to ensure only designated chemical types could be entered into the “Product_Type_User” table in the Oracle database. We noted eight products had been entered incorrectly, which resulted in the OES system adding the related transaction quantities to the “Miscellaneous” default category in error. Because the final report review process was being conducted at a very high level, these errors were not detected and the final report contained a minor level of misstatement” </li></ul></ul></ul>
    66. 66. More Information . . . <ul><li>GAIT Resources www.theiia.org </li></ul><ul><li>Questions? Ask Dr. GAIT [email_address] </li></ul>
    67. 67. Thank you!

    ×