To help internal audit departments manage ongoing challenges, a panel of experts convened for the May 2008, IIA webcast, “The Art of Assessing IT Controls.” In follow-up interviews with KnowledgeLeader, the participants shared their views on this topic.

 

When organizations look at assessing information technology as part of evaluating their overall control environments, it is a good idea to keep a steady gait – or rather, GAIT.  The Institute of Internal Auditor’s (IIA) Guide to the Assessment of IT Risks (GAIT) can be especially valuable when audit shops review IT General Controls (ITGC). “Little wonder – the original GAIT Methodology was developed in response to the difficulties of identifying the right scope for these controls,” says Norman Marks, vice president, governance, risk and compliance for Business Objects, an SAP company.

 

Previously, testing ITGCs as part of an assessment of controls over financial reporting consumed a tremendous amount of resources, notes Marks. Moreover, issues were being identified through deficiencies that were difficult to tie back to any financial reporting risk. “We seemed to be looking at issues that did not necessarily have relevance in terms of financial reporting risk. But they seemed important on business grounds nonetheless,” Marks says. That opened the door for GAIT’s development. “Just as we have GAAP – Generally Accepted Accounting Principles – the team thought we should have generally accepted IT practices, and that is what GAIT originally stood for,” Marks recalls.

 

Specific Risks Dictate IT Control Needs

Time overtook this original idea in two ways. First, it was recognized that no standard set of IT controls should be in place at all times; rather, needs should be identified based on the specific risks of a particular situation. Second, Sarbanes-Oxley (SOX) arrived. “As matters evolved, there developed a big need in the market for more clarity around what IT risks needed to be addressed in a SOX compliance project,” say Ed Hill, managing director, Protiviti. “So, GAIT was formed to write some literature about a rational thought process for scoping the IT work related to SOX compliance projects.” Hill adds that it might be more appropriate to refer to the original GAIT Methodology as the GAIT Methodology for Sarbanes-Oxley Compliance.

 

The result was developing a methodology that took a top-down approach, which was being pushed by the PCAOB and SEC staff, and helped organizations define the right scope of key controls for Section 404.  While some believe that GAIT was developed solely to help organizations cut costs by eliminating unnecessary ITGCs, it is not the case according to Marks. “GAIT helps organizations identify the right key ITGCs, the controls that have to be effective in order to prevent or detect a material misstatement of the financials.  In practice, we have found that companies have concluded the GAIT assessment with a significant number taken out of scope, but with a few added in.  The GAIT process has identified reliance on some applications, databases, data warehouses, etc. that had not been considered previously.  The net effect is a significant reduction.”

 

 

 

In December 2007, The IIA surveyed users of the original GAIT Methodology and the results are impressive:

• 97.2 percent reported that they found the methodology to be valuable, and 39.7 percent said the value was significant.
• 80.3 percent reported that they had been able to reduce the number of key controls by more than 10 percent; 50 percent reduced scope by more than 20 percent; and 34.8 percent achieved more than a 30 percent reduction.
• 94.2 percent said they would recommend GAIT to others.

 

That first GAIT, adopted in 2007 (but available in draft form and out for comment some 18 months prior), is what Marks calls a “logical reasoning process,” one that could be applied in different settings. Even before GAIT made its official appearance, one team developed a way of using GAIT to scope spreadsheet risks. Indeed, the feedback from early pilot adopters was incorporated into the final document.

 

The first GAIT document was then followed by other members of the GAIT family. “You can call them spin-offs, if you like: Special Victims Units of GAIT,” Marks says with humor. These include GAIT for IT General Control Deficiency Assessment (which is also more of a SOX-related document, according to Hill) and GAIT for Business and IT Risk. It is a family built around a common core of thinking.  GAIT for IT General Control Deficiency Assessment turns the GAIT Methodology, with its top-down approach from financial statement risk, through business process risk, down to ITGC risk – upside down. When the ITGCs do not work, “Follow that thread back up to understand the risks to the financial statements,” Marks says.

 

Kris Kahn, senior manager, IT governance, Seagate Technology LLC, calls GAIT, “an important methodology for any enterprise to ensure that its IT controls are appropriately aligned to business processes that support the financial statements.”

 

Focusing on Key Controls

For a company to optimize its ability to scope its IT controls, Kahn says, and to minimize the amount of SOX testing required (conducted internally and externally), reducing the IT controls to only key controls is essential for cost savings. A company’s ability to identify those controls, Kahn continues, in relation to the top-down risks, is critical to realistically prevent errors in the financial statements from an IT perspective.

 

As an example, Kahn points to change management in IT, which has defined controls for each of the different types of processes, including patch management and code management. Patch management controls could be applied to applications, operating systems, database systems and even network security devices such as routers and firewalls. “GAIT will help identify which of those components would be in scope for SOX and require key IT controls,” he says.

 

“Organizations may identify that network devices would not be in scope as the specific failure of an individual networking device would not have an impact on financial statements that could not be prevented or detected by existing controls,” Kahn explains. “Therefore, key IT controls need to be clearly identified within IT processes and throughout the IT infrastructure layers, evaluating their alignment to the key control definition. Additional IT controls that are non-key may not require the rigor of testing for SOX compliance, but should still be identified and documented in the IT control framework.”

 

 

The other, newest GAIT document – for IT and Business Risk – takes the scoping and guidance beyond financial reporting (covered by SOX) and looks at IT risks in the context of business risk. In a sense, it goes even further than that. “One of my colleagues says, and I repeat, ‘there is no such thing as IT risk. There is only business risk, which has IT implications’,” Marks says. “So, the idea was to make it a more generally applicable methodology that could be used not just for SOX, but also for compliance auditing, operational auditing or whatever, to make sure that we were considering all aspects of controls, both manual and automated.”

 

GAIT has its own built-in flexibility, so it is not surprising that companies are adhering to its principles, if not its exact approach. Marks says that is fine. “People should turn it to their specific needs and circumstances.” And while it is difficult to pin down who, exactly is using GAIT, there appears to be acceptance of it among the major CPA firms as well as other firms. “It will just continue to grow,” Marks predicts.

 

“We hear stories, and we hear about activity around the GAIT Methodology,” Hill reports. “We have heard a number of times that it has been successfully used to explain and assess companies’ choice of work around the IT area for SOX.”  According to IIA records, the methodology was downloaded more than 17,000 times through the end of March 2008.  The number of downloads for all members of the GAIT family is over 40,000.

 

Why GAIT Inroads are Slow in Coming

Kahn, for his part, says he has not seen major CPA firms, including the Big Four, embrace GAIT, primarily because they have their own established methodologies, which have different, and perhaps broader, scoping processes. “I have not yet seen any of the audit firms come to agreement on a key control for IT.” Will that eventually change? “There is opportunity within the GAIT Methodology for audit firms to take advantage of it,” Kahn says.

 

Hill notes that when GAIT was developed, there was an advisory board to The IIA – and the Big Four were all participants in that board. “They are all aware of it, they have all had input to it, and they all have been involved in it. They do not disagree with the principles that are there” – even if they do continue to prefer their own methodologies. “It all co-exists for them,” Hill says.  While the Big Four may not use GAIT, they all have a number of clients who use GAIT, and each of the firms has accepted that use.  One reason for this, according to Marks, is that GAIT provides solid and understandable documentation supporting the identification of key ITGCs.

 

Has GAIT assisted companies with SOX compliance efforts? Kahn says that when it comes to SOX, often IT and finance organizations operate from different perspectives. Finance, using the COSO model, employs a top-down perspective to assess the finance processes, essentially down to the application controls level. Traditional IT control scoping, on the other hand, would be bottom-up, identifying all the items that could potentially be related to risk to the IT organization.

 

“The benefit of applying GAIT is that IT controls are directly aligned with the IT dependencies identified to the application controls within finance processes,” Kahn says. “It minimizes the IT controls using the top-down, risk-based approach.” The alignment between IT and finance, he adds, “is really the biggest benefit.” Mapping the controls between IT and finance is critical; moreover, it allows companies to more easily determine the impact of potential IT control failures by following the risk back to the finance (business) processes, he says.

 

 

Most companies using the original GAIT have found it has assisted with SOX compliance, making significant reductions in the number of key controls, and therefore lowering costs. “They are going through an understanding of what is important and what is not, and they are much more assured that they have identified the right ones,” Marks says. And because GAIT exposes the logic of the actions, external auditors have perhaps increased their reliance on internal auditors’ work. In his firm’s last independent year, 2007 (as noted, it is now an SAP company), Marks says, the audit fee for SOX was less than 20 percent of the total audit fee. “This is phenomenal. They only tested one ITGC, and that was a re-performance of a limited sample size. They left everything else to us.”

 

Beyond SOX compliance, GAIT for Business and IT Risk will help companies understand the impact IT has on the business risks and what IT areas would need to be included in an audit of a business risk. Marks recalls an incident related to his organization’s convenience store business, in which the external auditors decided to audit the controls over the stores’ computers. They selected a sample of about 15 convenience stores and came back with a dire announcement: “The sky is falling,” as Marks puts, because of numerous control deficiencies. “We had a meeting with the external auditors’ IT partner and manager, the external auditors’ general practice partner and manager, the corporate comptroller, the head of SEC reporting, and me.”

 

The general manager for the external audit team then realized something crucial: The other controls in the head office would have detected any problems occurring in the stores. “What happened was these people went in and spent hundreds of hours and tens of thousands of dollars auditing something that turned out to be minimal in terms of its risk – because they started using a traditional check-the-box, this-is-important kind of approach. If they had taken a top-down approach, as GAIT would do, they would never have gone in there,” Marks says.

 

Taking a Top-Down Approach

It makes sense to employ a top-down approach for operational auditing as well, Marks continues, since it permits auditors to identify “what can go wrong” and hurt an organization, rather than just “what can go wrong” in principle.

 

Discussing the concept of ITGC, Hill notes that the GAIT Methodology for Sarbanes-Oxley Compliance tries to narrowly focus an organization’s IT work on those general control processes and general control areas that directly impact the accuracy, completeness, and consistency of financial statements, as opposed to taking a broader view. “The GAIT Methodology narrows the focus of the work, which then limits the amount of work.”

 

COBIT makes for an interesting counterpoint to GAIT. COBIT, of course, is a proven framework that helps organizations understand typical control objectives for IT and the controls that might be needed to satisfy those objectives. But it is IT-oriented and does not start with GAIT’s holistic, business risk, top-down approach. “COBIT does not necessarily have any specific scoping materials,” says Hill.

 

“COBIT can be used together with GAIT. They do not replace each other,” Marks says. “Once you understand your risks – for example, relating to change management of your financial systems, or security over your inventory system, or your MRP data – then you use COBIT to flesh that out, to say, ‘OK, I have these risks, now let us identify the related control objectives and what controls might be best suited to address those,’” says Marks.

 

 

Kahn calls COBIT an excellent framework that can support a top-down, risk-based scoping methodology. Similar to the way finance departments use COSO to identify the finance processes and related risks, COBIT can help IT design the IT control framework and significant IT processes. “Every company is going to have its own, custom IT control framework,” he points out. “Similarly, every finance organization will also have its own.” The goal, he says, is not for COBIT to be 100 percent adopted but for it to be used to help identify the IT processes and the supporting controls relative to the risks.

 

As Kahn points out, another benefit of COBIT is its business-focused. “It drives the alignment of the controls toward business goals that IT directly supports.” The IT Resources identified by COBIT, he says, are relative to the IT layers needed to evaluate where controls should be established to mitigate process risks. This would be within applications, around information and throughout infrastructure. Any number of challenges remain for internal audit organizations as they evaluate ITGC.

 

Eye on the Big Picture

One top challenge, Kahn observes, as an IT audit or internal audit organization reviews general computing controls, it will need to understand IT controls relevant to business risk. Without having the results of a GAIT Methodology exercise, then IT management will find it difficult to ascertain risk. “It is a more daunting task to clarify and prioritize the risk,” Kahn says.

 

As an overall trend among organizations, says Hill, there is an understandable desire to try to narrow the amount of work they need to do. GAIT can help with that by focusing on achieving business objectives, rather than on individual controls. “It is making sure you do not get lost in the trees, and not see the forest. You see why you are doing it.”

 

Marks sees a “tremendous, yet fun” challenge in looking at how to use continuous monitoring/auditing techniques to improve the effectiveness of ITGC testing. GAIT will help identify the risks. But the challenge is putting continuous monitoring/auditing to work. He says another challenge is endemic to ITGC: the complexity of ever-changing technologies and understanding the risks they represent. “But the beauty here is that GAIT will put them into context. It allows you to ask, ‘Do I really have a risk in the context of all my controls?’”

 

GAIT for Section 404 Compliance

Using the GAIT Methodology to perform top-down scoping, Kahn has worked directly with finance and IT SOX compliance teams to cooperatively map the IT controls to the finance application controls and business processes. The biggest benefit of using GAIT, he says, has been a growing awareness by finance and IT organizations of the need to review appropriate risks together and to identify any non-financial system that may be in scope for IT, but is not directly tied to a finance process. “Finance and IT always have different terminology, based on their key areas of expertise, and often specific terms will get misused or completely mangled,” Kahn says. It is “absolutely essential” that finance and IT establish an agreed-upon glossary of common terms to minimize the confusion and reduce misconceptions.

 

Performing GAIT as a joint finance and IT scoping project, Kahn says, is necessary to achieve the appropriate top-down control alignment. The first two phases of GAIT can be led by finance, while the third and fourth phase can be led by IT. “But by no means should those separations of leadership exclude the partnering organizations from participating. Both organizations should participate in all four of the GAIT phases.”

 

 

One challenge Kahn witnessed was that as Phases 1 and 2 were performed, finance identified what it could name as IT dependencies; however, those did not necessarily map exactly to what IT identified as a specific application or system name directly supported by IT. Without the appropriate IT knowledge for making the decision in Phase 2, there will be gaps based on the difference in viewpoint, he says. Finance organizations and business process owners may name an interface that they are used to using that would be critical to include within their SOX compliance. IT would look at either the application module or the system name, or even the database instance.

 

Despite these challenges, the overall improvements brought by GAIT’s use were not insignificant, Kahn says. IT controls can be scoped down to key controls that directly support financial and business processes. Any year thereafter, re-performing the GAIT exercise (which should be done on an annual basis or as new systems are introduced), changes in the business and its processes evolve or as the overall materiality of the SOX scooping process, can help validate the scope of SOX-related controls through finance and IT. This in turn will help ensure that the business risks are effectively mitigated. GAIT can also be useful to identify design gaps, where key controls need to be established; this will further prevent the possibility of material error.

 

Another benefit is simple but important. “Through a collaborative effort between finance and IT,” says Kahn, “there is the increased awareness surrounding the responsibilities of controls for ownership, testing and business support.”

 

Kahn offers the following recommendations:

• Document and communicate common agreed-upon terminology.
• Regularly perform top-down risk-based scoping and deficiency assessments using GAIT jointly between IT and business owners.
• Implement a change control process surrounding key controls, and communicate changes regularly between IT and finance.
• As new owners are introduced to relative roles for SOX compliance, include the GAIT Methodology in the training and awareness efforts.

 

Drilling down a bit more, Marks notes how ITGCs impact financial statement risk. The first thing organizations need to realize, he says, is that a checklist approach is insufficient. Each organization’s risks are likely to be different from the next one. Although an investment is required to go through GAIT, the return is manifold.

 

He has seen a tendency, at a couple of firms, to make SOX less important, more routine. “They are saying, ‘I do not need to assess the scope, because I am going to use the same scope as last year.’” That may be totally inefficient, Marks warns, because the business can change. “You may end up assessing and testing the wrong things.” And although he observes a sense among firms that the level of control reduction has become smaller, “For companies that have not used GAIT, there still is tremendous opportunity.”

 

GAIT for ITGC Deficiency Assessment

GAIT offers several aspects that are especially applicable for assessing ITGC deficiencies. “The reason it is so valuable for ITGC deficiency assessments, compared to business control deficiency assessments, is that ITGCs are more distant from the financial statements.  Assessing their significance is difficult,” Marks says. Looking at business process controls, it is fairly easy to discern relationships – the impact of accounts payable control issues on the financial statements, for example. Ditto for a problem in the applications systems for calculating inventory values, based on static costs. But with ITGC, distance clouds matters. “So GAIT helps you down that path and makes it easier to see relationships.”

 

 

He also notes the importance of the so-called reliance chain, which describes the relationship between the financial statements and the key ITGCs that have failed. As Marks explains, the financial statements depend on business controls, which include automated controls. The later may be dependent in turn on ITGC (with ITGC objectives added to the mix). The reliance chain shows these links; without it, it is simply impossible to know if a reliance relationship exists between ITGC and the financial statements. “Unless you understand how to trace the relationship on specific ITGCs all the way up to financial statements, you cannot determine how critical they are to those statements.”

 

One GAIT principle is that rather than assessing key individual ITGCs, you should determine whether ITGC objectives are achieved. Marks names an example – an ITGC objective that says all changes to application programs are properly approved. This may involve three controls in terms of actual procedures. “You cannot necessarily say that because one of them fails, the control objective fails,” he says. “You have to look at it in the context of the three.” The reliance chain provides that context.

 

Another key principle to consider is that of aggregation. GAIT does discuss this principle, primarily in the deficiency assessment, though it is also talked about in the original GAIT and, to a lesser extent, the GAIT for Business and IT Risk document. The point here, says Marks, is one ITGC, such as security, can affect multiple application controls, and through them can affect multiple areas of financial statements. One deficiency, in short, can be felt far and wide among applications, databases and risks, thus making the assessment of the deficiency a complex affair. “Especially when you have things like testing, which can apply to multiple applications. You really have to think through which critical functionality it can impact and see how that plays out along the reliance chain.”

 

GAIT for Business and IT Risk

This third component of GAIT, says Hill, was developed with a sense of completing the overall scoping structure for internal audits. The primary users of this are internal auditors, internal audit directors, and company personnel. “It is very clearly an internal audit-related methodology”, versus the SOX leanings of the other two GAIT documents. “This is specific guidance for internal auditors and how they should view scoping of the IT work around various business audit areas.”

 

The guidance brings clarity and focus to the scoping exercises. Moreover, Hill says, it points out the interdependency between IT controls and manual business controls. “It breaks down the business processes being audited,” he says, “by identifying what types of controls are necessary within that process.” Some are manual, some are automated – and some are semi-automated.

 

Hill explains, “Let us say someone looks at the output of a report and compares it to something else. The report has to be accurate for that control to work. There is a manual component (the review) and an automated component (the report), so we call the control semi-automated.  Find where the automated and semi-automated controls are, and understand what applications they are derived from. Then, within those applications, ask what kind of reliance you are placing on that application to obtain complete and accurate information. If for some reason the application did not work, is there any way for the users of that information to know that it did not work, such that it does not lead to ultimate error or issue for the company?”

 

Once those questions are answered, the next step is to ask, “What kinds of IT controls are in place to ensure consistent, continuous operations?” This can include managing changes over the program code. “That is how to determine the processing is complete, accurate and consistent – to have very strict controls over who can change the program code and what can be done to the changes before they move it into the live environment,” Hill says.