Guide to the Assessment of IT General Controls Scope Based on ...
Upcoming SlideShare
Loading in...5
×
 

Guide to the Assessment of IT General Controls Scope Based on ...

on

  • 4,482 views

 

Statistics

Views

Total Views
4,482
Views on SlideShare
4,481
Embed Views
1

Actions

Likes
0
Downloads
129
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • David Why was it formed?: Auditors and management are frustrated with IT aspects of SOX-404 compliance because current scoping approaches are creating overly broad scope and excessive testing costs SEC registrants are hesitant to reduce scope for fear of increasing risk and scrutiny Significant risks to financial assertions may be unaddressed due to lack of consistency SEC registrants and CPA firms both experience suboptimal use of scarce resources COSO provides an accepted construct for defining overall internal control objectives, assertions, risks and controls, but its application to the IT environment is ambiguous COBIT does not provide a clear mechanism to scope IT processes and controls to the achievement of specific internal control objectives (e.g., COSO objective for internal control over financial reporting) Does GAIT specify which controls an organization should use? GAIT does not identify specific key controls. Rather, it identifies the ITGC risks for which key controls need to be identified. Users of GAIT will employ other tools, such as COBIT, to identify and then assess specific ITGC key controls. Does GAIT only apply to SOX 404? At this time, GAIT focuses on risk assessment and scoping for the §404 assessment, but the principles can also be applied to the identification of controls for other assessment purposes (e.g., as part of an assessment of controls over compliance with applicable laws and regulations). Future editions are planned to provide guidance in some of those other areas. Is GAIT intended to reduce control counts? While not specifically designed to reduce control counts, we have found that organizations that shift their analysis to a top-down, risk-based approach are often able to eliminate redundant and other controls that do not represent a likely risk to the financial statements. As a result, reduced control counts will likely be achieved the first time a top-down and risk-based is used. We have also found that the top-down approach helps organizations improve their understanding of risks, which may lead to reassessing and changing which controls they will rely on.
  • - 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.
  • - 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.
  • As you move down the stack, the # of controls tend to increase As you move up the stack, the risk to the F/S & disclosures increases
  • As you move down the stack, the # of controls tend to increase As you move up the stack, the risk to the F/S & disclosures increases
  • - Norman Principle 1 The identification of risks and related key controls in IT business processes (e.g., in change management, deployment, access security, operations) 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. The assessment of risk within IT business processes should not start with a list or checklist of significant risks, but instead continue the risk assessment process that starts with the identification of significant accounts and locations, related assertions, business processes and major classes of transactions, potential points of failure, and key controls within the business processes. Other approaches are not likely to be linked to the risk of material misstatement of the financials and therefore may be ineffective and/or inefficient.
  • - Norman Principle 1 The identification of risks and related key controls in IT business processes (e.g., in change management, deployment, access security, operations) 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. The assessment of risk within IT business processes should not start with a list or checklist of significant risks, but instead continue the risk assessment process that starts with the identification of significant accounts and locations, related assertions, business processes and major classes of transactions, potential points of failure, and key controls within the business processes. Other approaches are not likely to be linked to the risk of material misstatement of the financials and therefore may be ineffective and/or inefficient.
  • Norman 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 objectives that, when achieved, mitigate the risks. COBIT and other methodologies can identify the key controls to address the ITGC 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)?
  • Norman Reviewing the key manual and automated controls and critical functionality The GAIT methodology begins with reviewing the key manual and automated business controls as well as critical system functionality. Figure 2 below illustrates how this phase fits into GAIT. The top-down assessment of business processes will have identified these key manual and automated controls. GAIT continues the top-down process by confirming the list, which is the basis for the GAIT assessment, and ensuring all critical IT functionality has been identified. The list is used to identify the financially significant applications, i.e., which applications will be considered “in scope” for §404 assessment and testing. Phase 1 To review the key manual and automated controls and key functionality Review the key controls, key reports, and other functionality in the company’s financial processes and determine which are manual and which are automated. From that, develop a list of critical IT functionality that is relied upon. The automated controls include: Fully automated controls (e.g., matching or updating accounts in the general ledger) Application functionality that manual controls rely on [1] , where an error in that functionality would not be detected (see also “Key report” on page 3). These are sometimes called “hybrid controls”. For example, a key control to detect duplicate receipts might include the review of a system report. The manual part of the control should detect inaccuracies in the report but would not be able to ensure that the report was complete. Therefore, the report would be in scope as a key report. By way of contrast, a bank reconciliation might use a report from the entity’s general ledger system showing the current balance, receipts, and disbursements. However, the normal operation of the reconciliation control would promptly detect an error in the report. So the automated portion of the control would not be key, only the manual portion. Confirm the key automated controls: Review the automated controls to ensure that they are key [2] . Organizations that had different teams determine risks and related controls in manual and automated processes, especially using a checklist or other bottoms-up approach, might have identified automated controls as key that should not be so classified. Assess whether, if the automated controls failed, there is at least a reasonable likelihood that a material error would not be detected. Sometimes there are manual key controls that would detect either a failure in an automated key control before it could lead to a material error or an unauthorized change to the data that is potentially material. You might be able to ensure these manual controls are identified as key and take the automated controls off the list of key controls. Determine whether there is additional critical IT functionality in the applications not identified as a key control, where a failure might not be detected and could reasonably lead to a material error in the financial statements. Many applications perform calculations and other procedures [3] that are relied upon in the processing of financial transactions and maintenance of related accounting records. These procedures are not strictly controls (see the definition of a control at page 3.) However, if the functionality failed, material errors might be introduced without detection from key manual or automated controls. Therefore, you need to include any such procedures as additional critical functionality and consider the risks to them. At this point, all the critical IT functionality should have been identified for each financially significant application. Identify the financially significant applications that are in scope for ITGC: Sort the critical IT functionality by application. The resulting list of applications with critical functionality is a list of the financially significant applications for which risks in IT business processes will be assessed (subject only to the next step). See the definition of a financially significant application on page 3. For applications that are not considered financially significant based on the presence of critical IT functionality, there is one additional step. That is to assess whether an unauthorized change directly to the application’s data could result in an undetected material error (see also “Principle 1” on page 3). This step determines whether a change to the data, bypassing the normal process and controls, could result in a material error in the financials that would not be detected by the normal operation of controls. If that is possible, the application should be assessed using GAIT, as a financially significant application. If not, the application can be considered out of scope. It should be noted that on occasion calculations and other functionality use data created in a prior application. Where a change to that data could result in undetected material error, the risk may lie not only within the application that uses the data but also in other applications (for example, the application where the data was created and any other applications where the data was stored and therefore at risk). Each of those upstream applications may be financially significant, if changes to the data in those applications would not be detected there or elsewhere. Continue only with financially significant applications. [1] ISACA’s “IT Control Objectives for Sarbanes-Oxley” describes these as “IT-dependent manual controls” or “hybrid” controls. [2] Consider the total cost involved when choosing between reliance and testing of manual or automated controls. Some have suggested that automated controls are more efficient and cost less than manual controls. The rationale is that testing manual controls is expensive as they have to be tested by sampling a (relatively) large number of transactions, and automated controls have to be tested only once. However, this assumes effective ITGC as the latter provide assurance that automated controls continue to function consistently, enabling a sample size of one. The cost of reliance on automated controls includes assessing and testing related IT business process key controls. While it is likely that many organizations benefit by relying more on automated than manual controls, each should make that determination carefully, considering all the costs and risks involved. Even if the automated controls remain key controls, manual key controls might be valuable when assessing risks in IT business processes related to the automated controls. [3] Some IT auditors use the term “programmed procedures” or “programmed accounting procedures” for these calculations, updating of ledger accounts, etc.
  • Norman Reviewing the key manual and automated controls and critical functionality The GAIT methodology begins with reviewing the key manual and automated business controls as well as critical system functionality. Figure 2 below illustrates how this phase fits into GAIT. The top-down assessment of business processes will have identified these key manual and automated controls. GAIT continues the top-down process by confirming the list, which is the basis for the GAIT assessment, and ensuring all critical IT functionality has been identified. The list is used to identify the financially significant applications, i.e., which applications will be considered “in scope” for §404 assessment and testing. Phase 1 To review the key manual and automated controls and key functionality Review the key controls, key reports, and other functionality in the company’s financial processes and determine which are manual and which are automated. From that, develop a list of critical IT functionality that is relied upon. The automated controls include: Fully automated controls (e.g., matching or updating accounts in the general ledger) Application functionality that manual controls rely on [1] , where an error in that functionality would not be detected (see also “Key report” on page 3). These are sometimes called “hybrid controls”. For example, a key control to detect duplicate receipts might include the review of a system report. The manual part of the control should detect inaccuracies in the report but would not be able to ensure that the report was complete. Therefore, the report would be in scope as a key report. By way of contrast, a bank reconciliation might use a report from the entity’s general ledger system showing the current balance, receipts, and disbursements. However, the normal operation of the reconciliation control would promptly detect an error in the report. So the automated portion of the control would not be key, only the manual portion. Confirm the key automated controls: Review the automated controls to ensure that they are key [2] . Organizations that had different teams determine risks and related controls in manual and automated processes, especially using a checklist or other bottoms-up approach, might have identified automated controls as key that should not be so classified. Assess whether, if the automated controls failed, there is at least a reasonable likelihood that a material error would not be detected. Sometimes there are manual key controls that would detect either a failure in an automated key control before it could lead to a material error or an unauthorized change to the data that is potentially material. You might be able to ensure these manual controls are identified as key and take the automated controls off the list of key controls. Determine whether there is additional critical IT functionality in the applications not identified as a key control, where a failure might not be detected and could reasonably lead to a material error in the financial statements. Many applications perform calculations and other procedures [3] that are relied upon in the processing of financial transactions and maintenance of related accounting records. These procedures are not strictly controls (see the definition of a control at page 3.) However, if the functionality failed, material errors might be introduced without detection from key manual or automated controls. Therefore, you need to include any such procedures as additional critical functionality and consider the risks to them. At this point, all the critical IT functionality should have been identified for each financially significant application. Identify the financially significant applications that are in scope for ITGC: Sort the critical IT functionality by application. The resulting list of applications with critical functionality is a list of the financially significant applications for which risks in IT business processes will be assessed (subject only to the next step). See the definition of a financially significant application on page 3. For applications that are not considered financially significant based on the presence of critical IT functionality, there is one additional step. That is to assess whether an unauthorized change directly to the application’s data could result in an undetected material error (see also “Principle 1” on page 3). This step determines whether a change to the data, bypassing the normal process and controls, could result in a material error in the financials that would not be detected by the normal operation of controls. If that is possible, the application should be assessed using GAIT, as a financially significant application. If not, the application can be considered out of scope. It should be noted that on occasion calculations and other functionality use data created in a prior application. Where a change to that data could result in undetected material error, the risk may lie not only within the application that uses the data but also in other applications (for example, the application where the data was created and any other applications where the data was stored and therefore at risk). Each of those upstream applications may be financially significant, if changes to the data in those applications would not be detected there or elsewhere. Continue only with financially significant applications. [1] ISACA’s “IT Control Objectives for Sarbanes-Oxley” describes these as “IT-dependent manual controls” or “hybrid” controls. [2] Consider the total cost involved when choosing between reliance and testing of manual or automated controls. Some have suggested that automated controls are more efficient and cost less than manual controls. The rationale is that testing manual controls is expensive as they have to be tested by sampling a (relatively) large number of transactions, and automated controls have to be tested only once. However, this assumes effective ITGC as the latter provide assurance that automated controls continue to function consistently, enabling a sample size of one. The cost of reliance on automated controls includes assessing and testing related IT business process key controls. While it is likely that many organizations benefit by relying more on automated than manual controls, each should make that determination carefully, considering all the costs and risks involved. Even if the automated controls remain key controls, manual key controls might be valuable when assessing risks in IT business processes related to the automated controls. [3] Some IT auditors use the term “programmed procedures” or “programmed accounting procedures” for these calculations, updating of ledger accounts, etc.
  • Norman Extending the understanding of the in-scope financially significant applications and their infrastructure At this point, you have a broad understanding of the financially significant applications. It was obtained during the earlier step (before GAIT starts) of identifying key controls and other critical functionality in the business processes. To continue the risk assessment, you need to understand more about the applications to determine where the risks are in IT processes. Organizations with multiple locations may be able to limit the scope of the §404 assessment (at the significant account and business process level) by focusing on significant locations. When assessing risks in IT business processes, consider whether the operation of the critical IT functionality is similarly limited to significant locations and identify where the related IT business processes are performed. For example, while the automated controls might only be performed at the headquarters and one other location (which are both in scope), changes to the application functionality might be made in a third location where the business processes are not considered significant. Conversely, while there might be IT business processes in a significant location, the IT department at that site might not be involved in maintaining the in-scope applications. The information required to complete the GAIT assessment falls into three broad categories: application infrastructure, related IT business processes, and risk indicators. To extend the understanding of the in-scope applications and their infrastructure Gather information about the following: Table 7: Additional application infrastructure and risk information CategoryDescription Application infrastructureThe following are typical items that are obtained to understand and assess risks at each layer of the application’s stack.The infrastructure elements that support the applications (e.g., databases, operating systems, networks, and data centers)The extent to which automated controls are the result of configuration settings rather than application codeThe database technology in use. Understand its nature and the frequency at which changes occur to database elements, such as schemas, that are essential to key automated controlsOperating system (e.g., what is used for which application and how often are changes made)Significant interfaces and the manual controls over them. You might need to add these to the list of key automated controls if they are not included as key controls, their failure would not be detected by the normal operation of key controls that have been identified, and they could lead to a material errorThe network infrastructure and its potential points of failure (e.g., the application and its key automated controls might be reliant on transmissions across the network, where a network failure or network security breach could reasonably likely result in an undetected material error in the financial statements)Was the application developed in-house, or is it a purchased application?Is the application maintained in-house or outsourced?How are the applications and infrastructure supported: centrally through shared services, geographically, or individually by business units?Are data center operations performed in-house or outsourced?Which network and technical infrastructure operations are performed in-house, and which are outsourced?How is IT organized? Is there separation of critical functions?Risk indicatorsCertain indicators could signal a higher level of risk in IT processes. These should be considered when assessing risk:How many and which key controls failed during prior period testing for §404 or during internal audits?What is the age of the application, and how often is it modified?Are there known problems with the processing or data?Are there known problems with any important application functionality?How extensively has a purchased application been modified, customized, and configured?What is the backlog of high-priority change requests?How often do processing problems occur?How often are emergency changes made?What is the level of staff turnover in key positions?
  • Norman Now that the critical IT functionality and in-scope financially significant applications have been identified and key related information obtained, the core of the GAIT assessment is performed. For each financially significant application, GAIT now takes each IT process at each layer in the stack and identifies the IT process risks and related control objectives. The challenge when assessing risk at this level, compared to risk in business processes, is that IT business processes are only indirectly linked the financial statements. In GAIT, IT process risk is assessed based on the risk it represents to the proper operation of the critical IT functionality. Another factor affecting the risk assessment is that many failures in IT business processes are more likely to be detected as part of normal operations than failures in general business processes. For example, if there is a security failure and a worm or virus invades the network, it is likely to be immediately apparent and its impact minimized. Therefore, there is a risk that an event may occur. However, if the nature of the event is such that it would be detected promptly, there is little risk of critical functionality failing without prompt detection – and therefore, the latter are unlikely to be the cause of a material error in the financial statements. When assessing risk, consider: The likelihood of an IT process failure occurring and its potential impact . There are a few steps involved in this assessment: What is the likelihood of the IT process failing in such a way that it would cause the critical IT functionality to fail? Is it at least reasonably likely that the critical functionality would fail without prompt detection and result in a material error in the financial statements? For §404 purposes, the focus is on IT process failures that are likely to result (through their affect on critical IT functionality) in material errors, not just errors of any size. Including IT process risks that are only theoretically possible but not likely, might lead to an inefficient §404 scope. Whether the error is deliberate (for the purpose of fraud or other damage) or inadvertent (accidental). For deliberate errors (e.g., deliberately inserting unauthorized code or changing data without authorization), remember that the only risks that should be in the focus of §404 are risks that are at least reasonably likely. This document does not guide the assessment of fraud risk but suggests that you assess fraud in the same way as in the business process. In other words, you should assess not only whether deliberate error is possible but also whether there are factors that make it at least reasonably likely (such as access to liquid resources, incentives for management to create fictitious transactions, and other risks identified during the assessment of the control environment).
  • Norman Now that the critical IT functionality and in-scope financially significant applications have been identified and key related information obtained, the core of the GAIT assessment is performed. For each financially significant application, GAIT now takes each IT process at each layer in the stack and identifies the IT process risks and related control objectives. The challenge when assessing risk at this level, compared to risk in business processes, is that IT business processes are only indirectly linked the financial statements. In GAIT, IT process risk is assessed based on the risk it represents to the proper operation of the critical IT functionality. Another factor affecting the risk assessment is that many failures in IT business processes are more likely to be detected as part of normal operations than failures in general business processes. For example, if there is a security failure and a worm or virus invades the network, it is likely to be immediately apparent and its impact minimized. Therefore, there is a risk that an event may occur. However, if the nature of the event is such that it would be detected promptly, there is little risk of critical functionality failing without prompt detection – and therefore, the latter are unlikely to be the cause of a material error in the financial statements. When assessing risk, consider: The likelihood of an IT process failure occurring and its potential impact . There are a few steps involved in this assessment: What is the likelihood of the IT process failing in such a way that it would cause the critical IT functionality to fail? Is it at least reasonably likely that the critical functionality would fail without prompt detection and result in a material error in the financial statements? For §404 purposes, the focus is on IT process failures that are likely to result (through their affect on critical IT functionality) in material errors, not just errors of any size. Including IT process risks that are only theoretically possible but not likely, might lead to an inefficient §404 scope. Whether the error is deliberate (for the purpose of fraud or other damage) or inadvertent (accidental). For deliberate errors (e.g., deliberately inserting unauthorized code or changing data without authorization), remember that the only risks that should be in the focus of §404 are risks that are at least reasonably likely. This document does not guide the assessment of fraud risk but suggests that you assess fraud in the same way as in the business process. In other words, you should assess not only whether deliberate error is possible but also whether there are factors that make it at least reasonably likely (such as access to liquid resources, incentives for management to create fictitious transactions, and other risks identified during the assessment of the control environment).
  • Norman Now that the critical IT functionality and in-scope financially significant applications have been identified and key related information obtained, the core of the GAIT assessment is performed. For each financially significant application, GAIT now takes each IT process at each layer in the stack and identifies the IT process risks and related control objectives. The challenge when assessing risk at this level, compared to risk in business processes, is that IT business processes are only indirectly linked the financial statements. In GAIT, IT process risk is assessed based on the risk it represents to the proper operation of the critical IT functionality. Another factor affecting the risk assessment is that many failures in IT business processes are more likely to be detected as part of normal operations than failures in general business processes. For example, if there is a security failure and a worm or virus invades the network, it is likely to be immediately apparent and its impact minimized. Therefore, there is a risk that an event may occur. However, if the nature of the event is such that it would be detected promptly, there is little risk of critical functionality failing without prompt detection – and therefore, the latter are unlikely to be the cause of a material error in the financial statements. When assessing risk, consider: The likelihood of an IT process failure occurring and its potential impact . There are a few steps involved in this assessment: What is the likelihood of the IT process failing in such a way that it would cause the critical IT functionality to fail? Is it at least reasonably likely that the critical functionality would fail without prompt detection and result in a material error in the financial statements? For §404 purposes, the focus is on IT process failures that are likely to result (through their affect on critical IT functionality) in material errors, not just errors of any size. Including IT process risks that are only theoretically possible but not likely, might lead to an inefficient §404 scope. Whether the error is deliberate (for the purpose of fraud or other damage) or inadvertent (accidental). For deliberate errors (e.g., deliberately inserting unauthorized code or changing data without authorization), remember that the only risks that should be in the focus of §404 are risks that are at least reasonably likely. This document does not guide the assessment of fraud risk but suggests that you assess fraud in the same way as in the business process. In other words, you should assess not only whether deliberate error is possible but also whether there are factors that make it at least reasonably likely (such as access to liquid resources, incentives for management to create fictitious transactions, and other risks identified during the assessment of the control environment).
  • - Steve - Build a team of business and IT experts Engage external auditor Complete GAIT early Ensure good understanding of automated controls – basis for GAIT Focus on getting scope right , not just on reductions Allow time to complete GAIT and review results Follow the methodology carefully Remember pervasiveness and reasonable person Call on Dr. GAIT if needed Document results carefully Explain both what is in and what is not in scope
  • - Steve - Build a team of business and IT experts Engage external auditor Complete GAIT early Ensure good understanding of automated controls – basis for GAIT Focus on getting scope right , not just on reductions Allow time to complete GAIT and review results Follow the methodology carefully Remember pervasiveness and reasonable person Call on Dr. GAIT if needed Document results carefully Explain both what is in and what is not in scope
  • - Steve - Build a team of business and IT experts Engage external auditor Complete GAIT early Ensure good understanding of automated controls – basis for GAIT Focus on getting scope right , not just on reductions Allow time to complete GAIT and review results Follow the methodology carefully Remember pervasiveness and reasonable person Call on Dr. GAIT if needed Document results carefully Explain both what is in and what is not in scope
  • - STEVE - Q&A With this slide up…

Guide to the Assessment of IT General Controls Scope Based on ... Guide to the Assessment of IT General Controls Scope Based on ... Presentation Transcript

  • GAIT G uide to the A ssessment of IT General Controls Scope Based on Risk A Top-Down, Risk-Based Approach to the Scoping of Key ITGC
  • GAIT
    • Topics Covered:
    • Problems with IT SOX Compliance
    • Overview / Advantages
    • Four Principles
    • Methodologies – Five Phases
    • Implementation
    • Examples
  • The Problem
    • Challenge defining an effective and efficient scope for the annual assessments of ICFR
    • Internal control assessments and testing by management and external auditors was not focused on risk of material errors (e.g., not following a risk-based approach)
    • Lack of established guidance (i.e., inconsistency and subjectivity, reliance on checklists, etc.)
    • CobiT and ITGI provide more scope than SOX expects, causing companies to do too much
    • Significant cost overruns
    • Difficulty defining the key IT general controls required to address risks of material errors to financial reports
  • What is GAIT?
    • GAIT provides a set principle and methodology that facilitates the cost-effective scoping of IT general control assessments
    • GAIT is a reasoned thinking process that continues the top-down and risk-based approach to assess risk in ITGCs
    • GAIT focuses on identifying risk in IT processes that could affect critical functionality needed to prevent/detect material errors
    • Control objectives are identified in GAIT, but not specific key controls
  • Why was GAIT formed?
    • Based on the problems described earlier, the IIA noticed the need to help companies identify key IT general controls where a failure indirectly result in a material error to the financial statements
  • Who helped with GAIT?
    • Core team of 7 people wrote and edited the documents
    • Christine Bellino, Jefferson Wells
    • Ed Hill, Protiviti
    • Fawn Weaver, Intel
    • Gene Kim, Tripwire
    • Heriot Prentice, The IIA
    • Norman Marks, Business Objects
    • Steve Mar, Microsoft – Team Leader
    • Advisory Board
    • CPA Firms – Big Four, Mid-sized Firms
    • SEC Registrants
    • Regulators
  • Who is a part of GAIT?
    • The Institute of Internal Auditors
    • IIA Support Staff
    • Advanced Technology Committee
    • Others
    • American Institute of Certified Public Accountants (AICPA)
    • International Federation of Accountants (IFAC)
  • How does GAIT work?
    • The GAIT document has two main parts:
      • Principles
      • Methodology
    • Four Core Principles
      • Define the relationship between business risk, IT general controls risk, and the IT general controls that can mitigate these threats as they pertain to financial reporting objectives
    • Methodology
      • Helps organizations to examine each financially significant application and determine whether failures in the IT general control processes at each layer of the IT infrastructure represent a likely threat to the consistent operation of the application's critical functionality – HOW TO APPLY THE PRINCIPLES
  • Advantages of Applying GAIT
    • Two Primary Advantages
      • Improves cost effectiveness of IT General Controls auditing by including within audit scope only the elements or layers of infrastructure and IT general control processes that are relevant to financial control risks.
      • Aids in the documentation of scoping decisions.
  • Overall GAIT Scoping
    • Significant accounts
      • Business processes
        • Business controls
          • Applications
            • General Controls
    RISK of material misstatement/fraud to financial statements & disclosures Scope SOX according to RISK of material misstatement/fraud.
  • IT Risk Assessment and Scoping
    • Significant accounts
      • Business processes
        • Business controls
          • Applications
            • IT Process Controls:
            • Change Mgt, Operations, Security
            • Application
            • Database
            • Operating System
            • Network
    STEP 1 : validate understanding STEP 2 : perform risk assessment at each layer STEP 3 : Conclude: is it REASONABLY LIKELY 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.
    • Controls may be assessed and tested that are not critical, resulting in unnecessary cost and diversion of resources
    • Controls that are key may not be tested, or may be tested late in the process, presenting a risk to the assessment or audit
    Risk of not using GAIT By not applying a top-down and risk based approach starting at the financial statements and significant account level, there is a risk that:
    • 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.
    • 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.
    • 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.
    • Risks in IT general control processes are mitigated by the achievement of IT control objectives, not individual controls.
    GAIT’s Four Principles
  • Financially Significant – Definition
    • Application: contains functionality relied upon to assure the integrity of the financial reporting process.
      • Should that functionality not function consistently and correctly, there is at least a reasonable likelihood of a material misstatement that would not be prevented or detected.
    • Data: data that, if affected by an 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.
    • . . . guides you by asking
    • three questions:
    • 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?
    • 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?
    • If such IT business process risks exist, what are the relevant IT control objectives?
    The GAIT Methodology
  • Phases of GAIT Methodology Identify controls over financial reporting to provide reasonable assurance as to their reliability Identify and validate critical IT functionality Identify significant applications where ITGCs need to be tested Identify ITGC process risks and related control objectives Identify ITGC to test that meet control objectives AS5 Phase 1 Phase 2 Phase 3 Phase 4 Perform a reasonable person review Phase 5
  • AS5
    • Top Down Approach
    • Effective internal control over financial reporting provides reasonable assurance regarding the reliability of financial reporting and the preparation of financial statements.
    • The auditor should use a top-down approach to the audit of internal control over financial reporting to select the controls to test. A top-down approach begins at the financial statement level and with the auditor's understanding of the overall risks to internal control over financial reporting.
    • Role of IT
    • The auditor should assess the extent of information technology ("IT") involvement in the period-end financial reporting process;
    • The identification of risks and controls within IT should not be a separate evaluation but, rather, an integral part of the auditor's top down risk assessment, including identification of significant accounts and disclosures and their relevant assertions, as well as the controls to test.
  • Methodology – Phase 1
    • Review key controls, reports, and other functionality in the company’s business processes and determine which are manual and which are automated.
    • Develop a list of critical IT functionality.
    • Confirm key automated controls.
    • Determine whether there is additional critical IT functionality not identified as a key control.
    Identify and validate critical IT functionality
    • Sort the critical IT functionality by application.
    • Identify the financially significant applications that are in scope for ITGC.
    Methodology – Phase 2 Identify significant applications where ITGCs need to be tested
      • Continue only with financially significant applications.
    Methodology – Phase 2
    • What is the likelihood of an IT process failure occurring and what is the potential impact ?
    • What is the likelihood of the IT process failing in such a way that it would cause the critical IT functionality to fail ?
    • Is it at least reasonably likely that the critical functionality would fail without prompt detection and result in a material error in the financial statements ?
    Methodology – Phase 3 Risk of IT Process Failures Identify ITGC process risks and related control objectives
      • Consider the pervasiveness of ITGC . . .
        • Are there risks that may affect multiple applications and their critical IT functionality?
      • Select Key IT general controls to test.
      • Link each key IT general control to the control objectives identified through GAIT.
    Methodology – Phase 4 Identify ITGC to test that meet control objectives
      • Confirm that the risks and key controls represent a reasonable view of risk to financial reporting.
      • Ensure that the selection of risks is reasonable, given the organization’s risk tolerance in their 404 scope.
    Methodology – Phase 5 Perform a reasonable person review
  • Implementation GAIT
    • Prior to implementing GAIT , companies should perform a top-down, risk-based assessment of their business processes and identify the key controls in those processes.
    • GAIT will utilize the information gathered from this assessment and define what functionality within the IT applications is critical and to see what IT applications provide this functionality.
  • Sample GAIT Matrix
  • Risk Factors
    • Factors that affect the risk associated with a control include:
    • The degree to which the control relies on the effectiveness of other controls (e.g., the control environment or information technology general controls);
    • Whether the control relies on performance by an individual or is automated (i.e., an automated control would generally be expected to be lower risk if relevant information technology general controls are effective);
  • Case Study 1
    • Energy Trading Company
    • Key IT general controls reduced from 48 to 20
    • Able to consolidate many of the controls
    • Added 2 applications due to reliance of financial controls
    • Identified other risk areas related to a key application
  • Case Study 2
    • Financial Institution
    • Eliminated 3 systems from scope – no controls dependent upon the systems
    • Able to eliminate all Network related controls except for access
    • Some controls were added back at management’s request due to the immaturity of the processes
  • Case Study 3
    • Utility Company
    • Reduced key IT general controls from 49 to 18
    • Reduction had significant potential for reducing administrative overhead
    • Paved the way for self assessment program
    • Able to provide good rationale for in-scope applications
  • Maximizing GAIT’s Implementation
    • Tips and Techniques
    • Start with a top-down, risk-based assessment of each risk and key control in the business process being evaluated
    • Build a team of internal controls experts with both business and IT knowledge to complete or review GAIT results
    • Engage external auditor
    • Perform GAIT assessment early in the process
    • Focus on getting scope right , not just on reductions
    • Document results carefully and be sure to explain what is and is not in scope
  • More Information . . .
    • GAIT Resources www.theiia.org
    • Questions? Ask Dr. GAIT [email_address]
    • Questions
    • Feel free to contact me with questions:
      • Bill McSpadden, CISA
      • Protiviti
      • 913-685-6200 or 913-661-7403
      • [email_address]