1. A Guide to Assessing the Scope of
The GAIT Methodology
A Guide to Assessing the Scope of
IT General Controls
A Top-Down, Risk-Based Approach to the
Scoping of Key ITGC

2. GAIT Topics Covered: Problems with IT SOX Compliance
Overview / Advantages of GAIT
The Four Principles
The Methodologies – Five Phases
Bonus discussion
Implementation
Examples

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

4. Why was GAIT formed?
Difficulty defining the key IT general controls required to address risks of material errors to financial reports
Based on these problems, 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
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. 4 4

5. Core team of 7 people wrote and edited the documents
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
- 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. 5 5

6. The Institute of Internal Auditors
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)
- 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. 6

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

8. The GAIT document has two main parts: Four Core Principles
How does GAIT work?
The GAIT document has two main parts:
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
Five Phase 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

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

10. Overall GAIT Scoping Significant accounts Business processes
RISK of material misstatement/fraud to financial statements & disclosures
Significant accounts
Business processes
Business controls
Applications
General Controls
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
Scope SOX according to RISK of material misstatement/fraud.

11. 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
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
STEP 3: Conclude: is it REASONABLY LIKELY a failure in this IT Process area
could impact application controls & result in a material misstatement?

12. Risk is not eliminated;
Reasonableness
Risk is not eliminated;
is it reduced to a
REASONABLE level.

13. Risk of not using GAIT
Ignoring a top-down and risk based approach starting at the financial statements and significant account level, increases the likelihood that:
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
- 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. 13

14. GAIT’s Four Principles
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.
- 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. 14

15. GAIT’s Four Principles
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.
4. Risks in IT general control processes are mitigated by the achievement of IT control objectives, not individual controls.
- 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. 15

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

17. . . . guides you by asking three questions:
The GAIT Methodology
. . . 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?
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)? 17

18. Phases of GAIT Methodology
Identify controls over financial reporting to provide
reasonable assurance as to their reliability
AS5
Identify and validate critical IT functionality
Phase 1
Identify significant applications where ITGCs need to be tested
Phase 2
Identify ITGC process risks and related control objectives
Phase 3
Identify ITGC to test that meet control objectives
Phase 4
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.
Perform a reasonable person review
Phase 5 18

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

20. AS5 (cont’d)
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.

21. Identify and validate critical IT functionality
Methodology – Phase 1
Identify and validate critical IT functionality
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.
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. 21

22. Real Life Examples
Depreciation expense is automatically computed from fixed asset system.
Hours transferred or keyed into ADP are reconciled to hours in E-time by a weekly hours report.
ADP reports are balanced against the hourly Kronos reports and the non-exempt employee manual spreadsheet.
Total dollars received daily are transmitted to Corporate Treasury from Data Control. These totals are added to the Daily Cash Control Statement for reconciliation by Corporate Treasury.
Billing Services receives an weekly with a report on Duplicate Meters…
The Work Management System used by the production groups assigns work order numbers to specific jobs and types of activities.

23. Real Life Examples (cont’d)
The Treasury Department records interest expense using the STX system.
Based on the actuary reports and payroll data, a memo is prepared and sent prior to January closing by the Lead Accountant to the Controller, Director of Accounting …
At the end of each month-end close, capital stock amounts are verified by Corporate Accounting with reports prepared by Investor Relations/ Treasury.
A pocket database is created that stores the last 15 days of read data and is maintained internally by IT. In the event of connectivity problems with MeterNet, these reads can be utilized to complete billing activities.
Meter read data is auto validated by the Validator-2000 application (meter reads are compared to meter pulse data) …

24. Some Systems Hiding Places
“Additional critical IT functionality not identified as a key control”
Some places to look:
Stock options
Taxes
Hedging activities (fuel, currency, inventory)
Depreciation
Reserves (warranty, pension, etc.)
Bonds/loans
__________________________

25. GAIT Bonus – Key Spreadsheets
Many organizations wrestle with properly identifying (scoping) and testing key spreadsheets
Overwhelmed by the number of spreadsheets
Some define key based on complexity, not necessarily significance
(Don’t forget Access databases, etc.)
GAIT approach offers a good approach to begin: What financial controls indicate spreadsheets?

26. Key Spreadsheets - Examples
Comparison of prepaid amounts to forecast and budget is performed monthly by the Staff Accountants.
Each month, Accounting will run a miscellaneous query and review the adjustments charged to the Dollar Scholar general ledger account.
Billing Services also populates an Excel spreadsheet in the Accounting E: drive with the reissued check number and amount.
An accountant in the Corporate Accounting Department maintains an Excel worksheet for fixed rate long-term debt, and an Excel worksheet for interest expense related to variable rate long-term debt.
Equity compensation worksheets and totals are reconciled to the Long Term Incentive Plan (LTIP) file from the Corporate Secretary’s office quarterly.

27. Identify significant applications where ITGCs need to be tested
Methodology – Phase 2
Identify significant applications where ITGCs need to be tested
Sort the critical IT functionality by application.
Identify the financially significant applications that are in scope for ITGC.
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
CategoryDescriptionApplication 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? 27

28. Continue only with financially significant applications
Methodology – Phase 2
Continue only with financially significant applications
(AND the applications used by IT to administer the ITGC)

29. Identify ITGC process risks and related control objectives
Methodology – Phase 3
Identify ITGC process risks and related control objectives
Risk of IT Process Failures
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?
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). 29

30. Identify ITGC to test that meet control objectives
Methodology – Phase 4
Identify ITGC to test that meet 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.
Consider the entire stack
Consider the nature of the stack
Are their common stacks
Link each key IT general control to the control objectives identified through GAIT.
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). 30

31. Processes within the Stack
IT Process Controls:
Process
Application
Database
O/S
Network
Change Mgt
Operations
Security
Etc…

32. Sample GAIT Matrix Build a team of business and IT experts
- 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 32

33. Perform a reasonable person review
Methodology – Phase 5
Perform a reasonable person review
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.
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). 33 33

34. Factors that affect the risk associated with a control include:
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);

35. Energy Trading Company
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

36. Financial Institution
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
At another financial institution was able to eliminate a whole class of servers and corresponding infrastructure

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

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

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

40. GAIT Resources www.theiia.org
More Information . . .
GAIT Resources
Questions? Ask Dr. GAIT
- STEVE -
Q&A
With this slide up… 40

41. Questions?

42. Feel free to contact me with questions:
Bill McSpadden, CISA
Protiviti or