247 Maitland Avenue
Altamonte Springs, FL 32701-4201 USA
Dr. GAIT Answers Questions from Web Event
QUESTION
1. Should middleware be included as a back-
end application, or should it only rely on
apps that support the front-end business
processes?
2. Are IT Governance Controls equivalent to
Company/Entity Level Controls? If yes, then
is it possible to scope out application
controls if company/entity level controls are
effective? Is it possible to do the same for IT
General controls?
3. Is GAIT implemented at small companies
the same way it is at large companies? Are
implementation processes consistent for
non-profits or religious organizations, or are
they unique for each type of entity?
4. Does the GAIT methodology differ for
Canadian IT auditors?
5. When applied to critical technologies such
as network and business continuity
programs, would the audits be considered
continuous reviews?
6. How does GAIT interface with COSO's ERM
integrated framework?
Tel: +1-407-937-1111
Fax: +1-407-937-1101
www.theiia.org
ANSWER
The top-down approach starts with setting materiality levels,
assessing company-level controls (such as those within the
control environment), identifying significant accounts and
locations, and then understanding the related business
process and major classes of transactions. That last step
includes understanding the applications involved in the
processing of the major classes of transactions, including
upstream and back-end applications. For example, if there is
reliance on key reports from a data warehouse or data mart,
there may be potential points of failure in ETL interfaces and
reliance on their functionality. If so, they become significant
applications.
There is no agreed-upon definition of IT Governance Controls,
which we believe are part of and should be assessed with the
organization's Control Environment, and other company-level
controls.
Automated application controls are included in the scope of
work for s404 if they are required to prevent or detect a
material misstatement of the financial statements. That
assessment is derived from the top-down and risk-based
approach.
There is no difference in how the GAIT methodology would be
used between large and small companies, or non-
profit/religious organizations. It is principles-based.
GAIT is principles-based, so it can be used to scope ITGC
process risks for the assessment of internal control over
financial reporting in any country.
We recommend defining the scope for the s404 assessment
based on a top-down and risk-based approach.
Other critical areas to the business can be separately identified
and audited based on risk.
COSO Internal Controls Framework can be used as the overall
internal control framework for assessing the system of internal
control over financial reporting. COSO ERM is not designed
as an internal control and should not be used for that purpose.
GAIT is used to apply the principles of the COSO framework,
identifying the risk within ITGC processes to the integrity of the
financial statements.
 QUESTION
7. How are GCC linked to or separated from
application controls when using GAIT?
8. How are network controls assessed through
this methodology? Please discuss Networks
in regards to LAN and WAN.
9. If I have already gone through a process to
identify ITGC, should I start over and use
the GAIT methodology?
10. When looking at application controls, are we
actually looking at the SDLC methodology?
11. How does one perform a significant account
assessment if the financial statements are
prepared by the parent company? Should I
rely on management sharing that
information?
12. Sometimes IT auditors do not understand
overall business objectives and are only
familiar with their own IT audit agenda. What
discussions should take place between
management and IT auditors/SOX 404
testers regarding significant risks relevant to
Financial Reporting?
ANSWER
ITGC provide assurance that the automated application
controls perform consistently and appropriately. GAIT
identifies the ITGC process risks to the key automated
application controls relied upon to prevent or detect material
misstatement of the financials. Key ITGC control objectives
and then specific key controls in ITGC can then be identified.
The network is part of the infrastructure of an application.
Once GAIT has identified an application as financially
significant, risks at all layers of the infrastructure of the
application (which include the network) are assessed. If a
failure in LAN or WAN processes and controls is at least
reasonably likely to lead to a failure in critical functionality, or
an inappropriate change to data that affects the financial
statements, then control objectives and key controls in ITGC
are identified.
If you are comfortable that you have an efficient and effective
ITGC scope, then you may choose to stay with it. GAIT is a
recommended but not required methodology. We suggest you
consider using it when there has been a change in the
business, such that reassessing the scope would be valuable.
We assume you are referring to the systems development life
cycle, which we have included in the change management
process when we discuss ITGC processes.
Automated application controls (as distinct from manual
application controls) exist in business processes such as
payables, inventory management, etc. ITGC provide
assurance over the continued proper operation of automated
application controls. When financially significant applications
are assessed using GAIT, change management at the
application layer is often in scope, with specific risks such as
insufficient testing or unauthorized changes. The systems
development life cycle typically includes a number of controls
that are key to addressing those risks: development, review
and approval of test plans, and the approval of changes to
applications.
The assessment of scope for the audit of internal control over
financial reporting should be performed by a team with both
business and IT understanding. It sounds from your question
as if you don't have insight into the business process, including
the preparation of the financial statements. We would have to
question why the assessment of ITGC scope apparently was
being performed separately.
The top-down approach that integrates the financial reporting
risks and the establishment of ITGC scope avoids this
problem.
 QUESTION
13. If an organization is making major revisions
to its change control technology and
infrastructure, should those areas be
included in the audit scope due to the risk
presented to the applications?
14. Would disaster recovery be considered key
ITGC controls in the GAIT methodology?
15. For companies that feel they are already
GAIT compliant, is there a recommended
pilot model that can be used to perform a
proof of value?
16. Would you suggest periodically re-
evaluating an organization's IT SOX controls
based on GAIT?
17. How should pervasive controls impacting
non-financially significant applications be
scoped?
18. How should I assess the monitoring of
controls of computer operations from the
perspective of ITGC SOX controls?
ANSWER
Changes to infrastructure of ITGC processes should be
included in scope as the result of a top-down approach. If
there are changes in an area that is not linked to the reliability
of critical IT functionality, there would not be a material risk to
the financial statements if those changes were not effective.
If an ITGC area was included in scope, then plans to make
changes would affect not only the timing of testing, but may
also affect the nature of the key ITGC controls. We
recommend including that as a factor in planning the testing of
the key ITGC controls. Consideration should be given to a
pre-implementation review of the changes.
PCAOB and SEC guidance is that Disaster Recovery is not
part of the scope for the s404 assessment of controls over
financial reporting. The reasoning is that while a disaster
might delay the filing of the financial statements, it is not a
likely cause of a material misstatement.
Companies can test their GAIT compliance by completing the
GAIT matrix, referencing the risk for each financially significant
application and its critical functionality to the key ITGC
controls. There should be a clear cause and effect
relationship, where the key ITGC controls are required to
provide assurance that the identified critical functionality
performs consistently and appropriately.
We reassess our GAIT analysis every year, as significant
accounts, business processes, key controls, and ITGC
processes tend to change.
There is no need to evaluate controls that affect non-financially
significant applications. Only risks to financially significant
applications need to be assessed.
The point we are making in GAIT is that a single ITGC risk
(e.g., the security of a service account) may not be a likely
source of a material error when looking at any one financially
significant application. However, if a failure to properly secure
that service account could result in a failure in several
applications, such that the overall risk of a material error is
likely, then the risk becomes in scope.
GAIT includes the process monitoring of computer operations
in the Operations process. Risks in the process at the various
layers are assessed to determine whether they represent a
risk to the critical IT functionality in each financially significant
application.
 QUESTION
19. How should service organizations under
SAS-70 or AU324 utilize GAIT?
20. How does GAIT address the scoping of
supporting infrastructure not likely to be
identified during the assessment of financial
applications and application controls, such
as interfaces, intermediate servers, or
databases?
21. How should GAIT be used when outsourced
vendors are involved with ITGC?
22. Is there guidance on how many controls a
company should have, reasonably based on
its size
(e.g. small, medium, large companies)?
23. We are now in the second year of the
certification process. Do you have any
suggestions or cautions for retrofitting the
GAIT methodology to an already defined
scope that perhaps could be "right-sized" in
using GAIT (e.g. in the rationalization
process)?
ANSWER
The top-down assessment process results in the identification
of critical IT functionality in financially significant applications.
GAIT identifies risks at the ITGC level relative to that critical
functionality.
If ITGC risks are addressed by controls performed by service
organizations, then assurance needs to be obtained of their
consistent operation. That assurance may be obtained from a
SAS 70 Type II report from the service organization.
The top-down approach starts with setting materiality levels,
assessing company-level controls (such as those within the
control environment), identifying significant accounts and
locations, and then understanding the related business
process and major classes of transactions. That last step
includes understanding the applications involved in the
processing of the major classes of transactions and potential
points of failure.
If there is reliance on interfaces, they are included either as
key controls or as additional critical IT functionality.
When GAIT is used to assess ITGC process risk at the various
layers of each financially significant application's infrastructure,
risks at the server or database level would be identified.
The top-down assessment process results in the identification
of critical IT functionality in financially significant applications.
GAIT identifies risks at the ITGC level relative to that critical
functionality.
If ITGC risks are addressed by controls performed by service
organizations, then assurance needs to be obtained of their
consistent operation. That assurance may be obtained from a
SAS 70 Type II report from the service organization.
There is no definitive number of controls that should be in or
out of scope, and there is no one size that fits all. Scoping is
carried out using the top-down risk-based approach, applying
judgment where appropriate. GAIT is a methodology to
support the scoping process and while this may reduce the
number of controls identified as key and tested, we prefer to
seek efficiency and effectiveness rather than any specific
reduction.
Our experience is that the best way is to set aside the prior
scope and objectively perform the GAIT process.
 QUESTION
24. Could you provide an example of a control
or control area that has been in scope for
SOX audits to date, that would no longer be
in scope using GAIT?
25. GAIT appropriately narrows scoping by
focusing on IT functionality related to
financial applications. For SOX 404
purposes, shouldn't scoping be narrowed
even more by further limiting the focus to
applications that affect financial statements?
26. Are reductions realized through GAIT
resulting from fewer in-scope systems, or
fewer key control activities?
27. Are companies using GAIT likely to reduce
or better manage external IT audit costs?
28. What is the most important result from
GAIT? IT control? IT reliability?
ANSWER
Certainly. One of our core team joined a company in year 3 of
their s404 program. In years 1 and 2, the sales order capture
system was included as a significant application.
The top-down approach was reviewed and reperformed, with
the result that no critical functionality was identified in the sales
order capture system. The only risk from failure of the
application was that sales orders would not be processed, and
this would not affect the financial statements. Therefore the
application was taken out of scope.
The same team member also assessed the risk in the network
infrastructure to those applications that were financially
significant. In prior years, security over the router tables was
included in scope and the external auditor had identified
related deficiencies. An examination of the risk was reviewed
with the external auditor and it was agreed that it was very
unlikely that an individual would attack the tables and insert
fraudulent transactions. Therefore, the area was removed
from scope.
GAIT focuses on financially significant applications containing
critical functionality required to prevent or detect material
misstatement of the financial statements. The top-down
approach achieves the objective in question.
This could be a combination of both. If you reduce the number
of items that are in scope, it follows that you shall have fewer
control objectives to review.
Our experience so far is that companies have been successful
in reducing the number of key ITGC process controls they
include in scope for s404. The external auditors have been
able to review the GAIT analysis and agree with the results.
As they typically rely on the same key controls as
management, this can result in a reduction of external auditor
costs.
GAIT is designed to enable the efficient and effective scoping
of ITGC risk to the financial statements and the identification of
related key controls within ITGC processes.
GAIT is currently not intended for use in identifying key
controls to ensure IT reliability or operational effectiveness.
That is one of the core team's next projects.
 QUESTION
29. How would an organization implement GAIT
in its third year of SOX implementation?
How receptive are external audit firms to this
methodology?
30. It seems we are all individually re-inventing
the wheel as we determine our main risks
and subsequent key controls in IT. Since
every IT infrastructure has pretty much the
same main risks and key controls, will the
IIA offer a recommended list of specific IT
Controls?
31. How can the GAIT approach for identifying
scoping be applied at our outsourcing
parties, when they come into scope,
considering the application and
infrastructure is managed by outsourcing
(internally)?
32. Like other controls that can indirectly impact
financial statements, physical security of IT
poses material risks. Does GAIT consider
physical aspects out-of-scope?
33. Please provide an example of functionality,
and elaborate on it in regards to the entire
methodology.
34. What guidelines are available for selecting a
"reasonable person?"
35. Should the audit committee be kept up-to-
date with this process? How involved should
the audit committee be in implementing
GAIT?
36. What recommendations do you have, if any,
for the use of Control Self-assessment (e.g.,
facilitated meetings) in this process?
ANSWER
Because the business changes each year, we recommend the
top-down assessment be reviewed at least annually. That
involves reassessing materiality, significant accounts and
locations, major classes of transactions, and key controls - and
reassessing or implementing the GAIT analysis.
While the CPA firms have not formally endorsed the GAIT
methodology, a well-documented GAIT analysis is a powerful
tool in discussing with them the scope of work for ITGC. Our
experience, with our companies, is that the CPA firms have
accepted our analysis.
We do not believe that there is a one-size-fits-all set of ITGC
controls that are always key. Each organization has different
business processes, applications, infrastructure, and risks.
The top-down approach is the only way to ensure an efficient
and effective scope.
The top-down assessment process results in the identification
of critical IT functionality in financially significant applications.
GAIT identifies risks at the ITGC level relative to that critical
functionality.
If ITGC risks are addressed by controls performed by service
organizations, then assurance needs to be obtained of their
consistent operation. That assurance may be obtained from a
SAS 70 Type II report from the service organization.
Physical security risks are considered within the Operations
process, and should be assessed for each financially
significant application. Each organization should assess
whether a failure of physical security is at least reasonably
likely to result in a failure of critical IT functionality or the
material change of data leading to a material misstatement of
the financials.
We recommend the scenarios, which have been published on
the IIA Web site.
The 'reasonable person' test requires you to stand back and
question what a reasonable person (who may or may not be a
real person) would think. This does not require bringing in
somebody to act as that person; it is more of an allegory.
Our experience is that the Audit Committee may like to know
that you are using this approach, but as long as they know the
external auditor is comfortable with the approach the members
usually don't probe.
Facilitated meetings would be an excellent way to complete
the GAIT analysis, with participation from business and IT.
 QUESTION
37. Which upstream applications that feed other
applications might be significant? Where can
you stop testing controls over applications
feeding the general ledger, versus going to
the original source of the data?
38. How do you determine a key IT control,
versus a non-key control? Is there a
guidance on this?
39. If an organization uses an off-the-shelf
accounting software package (such as
Oracle), what approach do you take in
auditing controls built into the package (i.e.
duplication payment)?
40. Many financial-related applications rely on
restricted access or SOD. How would you
estimate the risks related to this by
privileged users? Isn't that always a high
risk?
41. How would you suggest ensuring that
automated controls are understood when
the business community is not well versed in
technology, and the IT community does not
fully understand overall business objectives
and critical areas of business that have a
financial impact? Is there a gap?
ANSWER
The top-down approach starts with setting materiality levels,
assessing company-level controls (such as those within the
control environment), identifying significant accounts and
locations, and then understanding the related business
process and major classes of transactions. That last step
includes understanding the applications involved in the
processing of the major classes of transactions, including
upstream applications. If there are potential points of failure in
the upstream business processes, and key automated controls
or other critical IT functionality are identified in the upstream
applications, then they become significant applications.
A key control is one that, as a result of a top-down assessment
process, is required to prevent or detect a material
misstatement of the financial statements.
We recommend a top-down approach. Key automated
controls (identified from the top-down approach) in packaged
software still need to be tested. Consideration should be given
to benchmarking (also known as baselining) techniques.
The top-down approach is the way to identify whether there
are key restricted access or segregation of duties controls.
They are not always a high risk from the perspective of internal
control over financial reporting.
Where a key control relies on limitations in the application over
who can perform a function (e.g., limits in the software on who
can approve journal entries or purchase orders), that restricted
access control is probably key.
If a pair of access rights represents a likely method for an
individual to divert assets, then that SOD control may be key.
When considering internal control over financial reporting,
there has to be at least a reasonable likelihood that the
scheme would not only result in a theft or fraud, but also one
that results in a material misstatement of the financial
statements.
GAIT is currently focused on the risks to the financial
statements. However, RA and SOD controls may be essential
to protect the business, and should be subject to periodic
audits for that purpose.
We have seen that situation, which is why we included a step
in GAIT to validate the automated controls, including obtaining
a good understanding of the related applications. We have
recommended that the GAIT assessment be performed by a
team with both business and IT representation.
 QUESTION
42. Does GAIT provide sample control
objectives that companies can use to assess
their applications, databases, operating
system and network layers?
43. What types of documentation are sufficient
(meeting minutes, white papers, flow charts,
narratives, etc.)?
44. If one control fails, out of five, does that
mean the control objective failed?
45. With respect to control exception analysis,
the GAIT guidance points out that it is
possible for an individual control to fail, but
when examined for its relationship to the
Control Objective, there is no significant
increased risk. Do external audit firms
generally understand and accept this
concept in 404 audits?
46. Were scheduled (batch) jobs and data
transformation services (DTS) on SQL
servers discussed in your consideration of
either application or database layers?
47. How long would you expect this process to
take for a $2 billion organization?
48. How does end-user computing
(spreadsheets) apply to GAIT -- is it
considered an application or process?
49. Would Excel spreadsheets fall within the
scope of GAIT if they support key financial
reporting processes such as revenue or
disclosures?
50. Considering that Microsoft has already
implemented GAIT, are their SOX 404 test
results, objectives, etc. available as an
example?
51. Was there a Year-2 at Microsoft?
52. GAIT is focused on General Controls linked
to financial reporting controls. How does
GAIT apply to general operational
controls/operational audits?
ANSWER
GAIT does not include sample control objectives, and we
recommend COBIT as a source.
GAIT does not require any particular form of documentation,
only that which is sufficient for an objective reviewer to
understand the process and results. We have recommended
the GAIT Matrix and the GAIT template.
A failed control does not necessarily mean a failed control
objective. Only a careful assessment, based on facts,
circumstances, and judgment, can determine that.
Our experience is that we are able to work with the CPA firms
when assessing deficiencies found during testing. If a single
control fails but does not cause the entire control objective to
fail and there is no increased risk to the financial statements,
the CPA firms generally will agree that only a control
deficiency exists.
The GAIT core team includes these in the Operations process
at the database layer. The GAIT analysis's processes and
layers can be tailored for each organization.
It would be difficult to determine how long it would take to
apply GAIT as that would depend on the complexity and
number of systems that are involved in the financial reporting
process.
A member of our core team has used GAIT effectively to
assess risk, controls objectives, and controls around
spreadsheets. However, GAIT was not designed for that
purpose.
A member of our core team has used GAIT effectively to
assess risk, controls objectives, and controls around
spreadsheets. However, GAIT was not designed for that
purpose.
We have supplied a GAIT scenario on our Web site. The
scenario and other guidance can be downloaded at
http://www.theiia.org/guidance/technology/gait/
Microsoft has assessed its control over financial reporting each
year.
At this time, we have focused GAIT on controls related to
financial reporting. We are working on the next stage:
adapting the Methodology for other types of risks and audits.
 QUESTION
53. From a governance viewpoint, what is the
role of an IT Steering Committee in
overseeing the GAIT implementation?
54. Many different methodologies can render
efficiencies. What specifically separates this
set guidelines from all others? What makes
it truly unique?
55. The GAIT is similar to "IT Control
Rationalization," which organizations have
been struggling with. How is GAIT different?
56. What tools and practical guidelines will be
provided?
57. Why shouldn't "other critical IT functionality"
at the business process level always be
included in ICFR documentation as key
controls (no matter whether the functionality
is of pure control nature)? Wouldn't this help
to avoid confusion?
58. Have any organizations performed a
cost/benefit analysis of GAIT?
59. Can rotation plans for TGC testing be used?
60. Does the ITGC assessment need to be done
after the application controls have already
been established?
61. Is it necessary to test automated application
controls more than once, if company level
controls over IT are tested and deemed
effective?
ANSWER
The GAIT assessment and implementation should be
overseen by both business and IT management, not just IT.
We recommend an integrated s404 Steering Committee.
GAIT distinguishes itself by flowing directly from the top-down
and risk-based approach recommended by the SEC and
PCAOB. It is part of a fully integrated approach considering
business risk. The core GAIT team itself was an integrated
business and IT expert team. Most other approaches in this
area were developed by IT experts, not an integrated team
with a more holistic business view and experience.
GAIT is a structured reasoning process that helps you identify
and then justify which are the right controls to test, rather than
an exercise in limiting the number of controls. It usually results
in a reduction of controls because many are included based on
a checklist, feel, judgment, or experience rather than a
structured reasoning process that ties risk to the financial
statements to the controls necessary to prevent or detect
material errors.
We have provided the GAIT Principles, Methodology and
scenarios on our Web site at
http://www.theiia.org/guidance/technology/gait/
There will be a workshop on GAIT at our General Audit
Management conference in Orlando, Florida in March, and at
our Technology conference in Scottsdale, Arizona in May.
Details of these events can be found at
http://www.theiia.org/iia-training/conferences/
Users may choose to include all critical IT functionality as key
controls (and some of the core team members have done so at
their companies). We have asked that GAIT users look for
additional critical IT functionality because often it is not
completely identified when reviewing the business process and
identifying key automated controls.
All of us who have used GAIT have obtained significant cost
reductions. Although there is a cost of implementation, the
reduction in key controls has significantly outweighed the cost.
The SEC has guided management to obtain "reasonable
evidence" to support its assessment of internal control over
financial reporting. This would require reasonable evidence of
the proper operation of key controls. That reasonable
evidence has to be obtained each year. Each company will
have to assess whether rotational testing meets that objective.
The assessment of ITGC process risk cannot be completed
until the key business controls, including key automated
controls and other critical functionality, are defined.
The guidance from the SEC and PCAOB supports testing
automated controls once (so-called test of 1) if related ITGC
key controls are effective.
 QUESTION
62. How does GAIT take into account the quality
of monitoring manual controls?
63. Where do the principles and methodologies
described here stop, and "personal
judgment," "gut feeling," and experience kick
in?
64. Can GAIT be applied more easily after all
key business processes and accounts have
been risk assessed with a top-down
approach?
65. How does the ITGC risk around the general
network and operating system impact the
top-down risk-based approach? What level
of control testing is needed?
66. Who were the survey respondents?
67. Where can I download a copy of the
guidance?
68. Was the OCC a part of the reviewing
Advisory Board?
69. Will you provide an example or "case study"
where the GAIT principles are applied?
70. What are some differences between the
objectives versus individual controls in
Principle 4?
ANSWER
GAIT is part of an integrated top-down and risk-based
approach that starts with company-level and business controls.
If monitoring/manual controls mean that there is no reliance on
key automated controls or other critical IT functionality, then
GAIT does not have to be used to assess related ITGC risks.
For example, if there are manual controls to ensure the
completeness and accuracy of an interface between the ERP
and a data warehouse, there is no reliance on that
functionality. The manual controls are sufficient to detect any
failure. Therefore, that would not be part of any critical IT
functionality where GAIT is used to assess related ITGC
process risks.
The scoping process for any assessment, any audit, relies on
judgment and experience.
The assessment of ITGC process risk cannot be completed
until the key business controls, including key automated
controls and other critical functionality, are defined.
The network and OS are part of the infrastructure of an
application. Once GAIT has identified an application as
financially significant, risks at all layers of the infrastructure of
the application (which include the network) are assessed. If a
failure in OS, LAN, or WAN processes and controls is at least
reasonably likely to lead to a failure in critical functionality, or
an inappropriate change to data that affects the financial
statements, then control objectives and key controls in ITGC
are identified.
Responses to the survey conducted just prior to the webcast
were mainly IT managers and IT auditors.
The GAIT guidance materials which consist of the Principles,
Methodology and a less complex scenario can be found at
http://www.theiia.org/guidance/technology/gait/, and the Web
event archive and presentation can be found at
http://www.theiia.org/recent-iia-news/?i=3168
The OCC was not involved in our Advisory Board
The GAIT guidance materials which consist of the Principles,
Methodology and a less complex scenario can be found at
http://www.theiia.org/guidance/technology/gait/, and the Web
event archive and presentation can be found at
http://www.theiia.org/recent-iia-news/?i=3168
One objective could be that all application changes are tested
prior to implementation. Individual controls could include the
development of test plans, the review and approval of the test
plan, and the review and approval of completed testing.
 QUESTION
71. Should the application layer be considered
the most critical for financial reporting risks,
with less focus on network, operating
system and database level failures?
72. How do you determine the difference
between control and function?
73. Does the methodology provide a clear
definition of "key control?"
74. Does the GAIT guidance clearly define
"significant applications?"
75. Will samples of the matrix and other
documents be available?
76. Why are objectives being designed after
control activities? Doesn't it make more
sense to have a company identify the
objectives they want to meet and then
identify controls?
77. What is an example of an ITGC control that
would lead to a material misstatement in the
financial statements?
78. Could you give me an example of "Critical IT
Functionality?"
79. How do you determine the likelihood of a
financial statement error, given that a ITGC
may not be effective?
80. When discussing application code,
databases, networks, and operating
systems, how are tables considered?
ANSWER
We believe each layer has to be assessed and explanations of
the results documented.
A control provides assurance of a desired outcome. COBIT
has this definition of internal control: "The policies, procedures,
practices and organizational structures, designed to provide
reasonable assurance that business objectives will be
achieved and that undesired events will be prevented or
detected and corrected".
The GAIT Methodology has a number of definitions, including
that of a key control:
"A control that, if it fails, means there is at least a reasonable
likelihood that a material error in the financial statements
would not be prevented or detected on a timely basis. In other
words, a key control is one that provides reasonable
assurance that material errors will be prevented or timely
detected."
GAIT includes a process for identifying financially significant
applications. It is in Phase 2 of the Methodology.
The GAIT guidance materials which consist of the Principles,
Methodology and a less complex scenario can be found at
http://www.theiia.org/guidance/technology/gait/ and the Web
event archive and presentation can be found at
http://www.theiia.org/recent-iia-news/?i=3168
We refer to Control Activities as a layer in the COSO
Framework. Individual key controls are identified to meet the
identified ITGC control objectives.
ITGC control failures do not lead directly to a material
misstatement of the financial statements. However, they can
lead to the failure of an automated application control (or to the
lack of assurance that the automated control functions
consistently and appropriately) that is required to prevent or
detect a material misstatement.
Critical IT functionality includes automated application controls,
key reports, and other functionality such as the updating of the
general ledger, performance of calculations, etc.
The assessment of likelihood is a matter of judgment, based
on experience and a review of specific facts and
circumstances.
"Tables" is a generic term that can be used for a variety
purposes, including the contents of a database, router code,
etc.
 QUESTION
81. Does the GAIT methodology take into
consideration errors that are less than
material, and more than inconsequential,
that could aggregately lead to a material
error?
82. What is a 404 scope?
83. In a transaction processing environment
where multiple applications are processing
revenue transactions, what's a reasonable
percentage of coverage to adequately cover
the organization?
84. What is an example of when security,
access controls, and operating system
controls would not be key controls?
85. How does GAIT apply in various situations
involving availability risk versus financial
risk, such as an infrastructure process
failing, but only impacting system
availability?
86. How should this new guidance be
implemented by organizations, like
ourselves, that are already using similar or
identical methodologies?
ANSWER
The top-down and risk-based approach considers the risk of
aggregation, and so does GAIT. However, there has to be a
reasonable likelihood of aggregation. For example, the
probability of multiple events occurring without a common
cause is the product of their probability. But, the failure of a
single ITGC key control could result in the failure of multiple
automated controls, as several automated controls rely on the
operation of the same control.
404 refers to Section 404 of the Sarbanes-Oxley Act of 2002,
which requires management to perform an annual assessment
of its system of internal control over financial reporting.
We assume that this question refers to whether all the
applications need to be included in scope.
The top-down process includes identifying major classes of
transactions. If the transactions processed by any individual
application are not significant, then that class would generally
not be included in scope and neither, then, would the
application.
The key is that management and the external auditor both
have to include in their scope of work testing of controls that
provide reasonable assurance that material misstatements
would be prevented or detected. There is no required
percentage coverage.
The selection of key controls would depend on the nature of
the critical IT functionality and the overall environment of
controls, both manual and automated.
If an application contains automated controls that are key, but
there is no risk of unauthorized changes to the data used by
the application, then security of the data may not be a risk in
ITGC process. Only change management might be included.
For example, if the data in a data warehouse is reconciled
daily to the ERP, then the risk could be limited to the reliability
of the reports.
With respect to s404, the SEC has provided guidance that the
only risk to be assessed is that of material error in the financial
statements. Delays in filing are not considered in scope for
s404.
We are pleased to hear that this process has been used
successfully by others. The Methodology that we have
published includes guidance for others to follow your lead.
 QUESTION
87. Would technology such as security patch
management or anti-virus be possibly
considered in scope for operating systems
because it is reasonably likely that critical
functionality (like access control on a
database server) may become ineffective?
88. Can you please define "reasonable
likelihood?"
89. When asking questions for each cell in the
GAIT matrix (suggested in Phase 3) how do
you best define the following criteria: "such
that one or more (critical functionalities)
becomes ineffective?"
90. What factors determine the "likelihood" a
risk will impact the effectiveness of a
control?
91. If there is a mitigating control in the
business, such as reconciliations, do you
still need to test the IT critical functionality
(i.e. system interfaces), if you are going to
be testing the reconciliations in the
business?
92. How would an automated control regarding
the approval of travel expenses (if failed)
result in a material misstatement?
93. Is there a standard set of key applications
that would always be within scope of SOX IT
General Controls review?
ANSWER
The network and OS are part of the infrastructure of an
application. Once GAIT has identified an application as
financially significant, risks at all layers of the infrastructure of
the application (which include the network) are assessed. If a
failure in OS, LAN, or WAN processes and controls is at least
reasonably likely to lead to a failure in critical functionality, or
an inappropriate change to data that affects the financial
statements, then control objectives and key controls in ITGC
are identified.
GAIT relies on the guidance from the SEC and PCAOB on
reasonable likelihood. The IIA's "Sarbanes-Oxley Section 404:
A Guide for Management by Internal Controls Practitioners"
suggests a probability of 5% is required, but the formal
guidance from the regulators relies on the application of
judgment and not a formula. Likelihood will always be a
subjective assessment. Each situation needs to be assessed
based on its specific facts and circumstances.
The user is encouraged to use their judgment when
determining whether a failure in an ITGC process such as
change management in a layer such as application code would
affect critical functionality negatively.
The assessment of likelihood is a matter of judgment, based
on experience and a review of specific facts and
circumstances
GAIT is part of integrated top-down and risk-based approach
that starts with company-level and business controls. If
monitoring/manual controls mean that there is no reliance on
key automated controls or other critical IT functionality, then
GAIT does not have to be used to assess related ITGC risks.
For example, if there are manual controls to ensure the
completeness and accuracy of an interface between the ERP
and a data warehouse, there is no reliance on that
functionality. The manual controls are sufficient to detect any
failure. Therefore, that would not be part of any critical IT
functionality where GAIT is used to assess related ITGC
process risks.
ITGC control failures do not lead directly to a material
misstatement of the financial statements. However, they can
lead to the failure of an automated application control (or to the
lack of assurance that the automated control functions
consistently and appropriately) that is required to prevent or
detect a material misstatement.
There is no standard set of key applications. The assessment
should be top-down and risk-based, as each organization has
its own business processes and applications
 QUESTION
94. Has there been a recent case where
financial statements were materially
misstated due to an IT weakness? If yes,
what was the IT weakness that caused the
material?
95. What practical example can be given on
how to connect a business process control
or objective to a ITGC objective and key
control?
96. What is COBIT?
97. Can you contrast and compare GAIT with
ISACA`s CobiT 4.0?
98. GAIT is consistent with SEC and PCAOB
guidance endorsing a "risk based"
approach. How can this be taken one further
step, such as using 302 reporting to
minimize scope?
99. How does the GAIT methodology integrate
with the new AS 5 standard?
100. Should companies receive buy-in from their
external auditor on using the GAIT
methodology?
101. Have external audit firms or the PCAOB
endorsed GAIT?
ANSWER
When assessing the quality of internal controls, there has to be
reasonable assurance that material misstatements would be
prevented or detected.
The good news is that there have not been many material
weaknesses reported as a result of ITGC control failures. That
is consistent with our experience, which is that ITGC failures
are not a common cause of misstatements.
However, they have happened and have included misstated
revenue from billing failures.
GAIT is the process used to do this. We refer you to the
Methodology, which can be downloaded from the IIA Web site.
The Control Objectives for Information and related Technology
(COBIT) is a set of best practices (framework) for information
(IT) management created by the Information Systems Audit
and Control Association (ISACA), and the IT Governance
Institute (ITGI) in 1992.
GAIT is a process for defining the scope of ITGC for the
annual audit of the financial statements. COBIT is a broader-
based standalone framework for IT controls. GAIT can be used
to identify ITGC risk, and COBIT is a solid tool for identifying
the related control objectives and key controls.
We have recommended to the SEC that they provide guidance
to companies on the integration of the s404 and s302
assessments.
The announcement of GAIT was delayed so we could review
both SEC and PCAOB draft proposed guidance. No changes
are anticipated to GAIT from the revision of AS/3
We strongly encourage companies to work closely with their
external auditor at each stage of the GAIT process.
The CPA firms will not formally endorse a methodology such
as GAIT. However, our experience is that they are receptive
to reviewing and working with companies who have
implemented GAIT.
The regulators will not formally comment nor endorse
methodologies such as GAIT. However, we have reason to
believe that GAIT is not inconsistent with their guidance
 QUESTION
102. Was ISACA consulted as GAIT was
developed?
103. External firms have been inconsistent in
defining and testing ITGC from year to year.
Will there be any upcoming guidance for
them on what to focus on?
104. Are the large accounting firms that are
conducting SOX attestations applying the
GAIT methodology globally or only in North
America?
105. We are a U.S. public company. Will our
SOX auditors rely upon GAIT for their audits
of our IT controls? Or is GAIT only valid for
our own internal control testing?
106. How can I get more information on
implementing GAIT, ideally communicating
with someone that has completed an
assessment?
ANSWER
ISACA was invited to participate in the GAIT Project but
elected not to do so. There was also a public exposure draft
release of the guidance which allowed anyone to comment;
ISACA elected not to provide formal comment. However it
should be noted that GAIT was developed by a large number
of individuals that hold the CISA designation or are active
ISACA members, including several who are reviewers and
contributors to the COBIT documents.
While the CPA firms have not formally endorsed the GAIT
methodology, a well-documented GAIT analysis is a powerful
tool in discussing with them the scope of work for ITGC. Our
experience, with our companies, is that the CPA firms have
accepted our analysis.
At this time, the larger CPA firms have not adopted the new
GAIT Methodology.
While the CPA firms have not formally endorsed the GAIT
methodology, a well-documented GAIT analysis is a powerful
tool in discussing with them the scope of work for ITGC. Our
experience, with our companies, is that the CPA firms have
accepted our analysis.
Please contact DrGAIT@TheIIA.org