control, and governance
Increasingly internal auditors must provide assurance on technology risks that could impact key business processes.
Neil Baker
Freelance Writer
The prospect of assessing IT risks can bedaunting for internal auditors who aren’t technology specialists. They might wonder, “Do I have the expertise for the job?” As an IT audit director, that wasn’t the obstacle that Lorie Reynolds had to overcome when she worked on an IT risk assessment for a former client. Her biggest headache was the company’s overly conservative approach to IT controls testing during its early years of compliance with the U.S. Sarbanes-Oxley Act of 2002. Terrified of messing up the organization’s compliance with the law, which requires U.S.-listed companies to attest to the effectiveness of their financial reporting controls, executives followed the safety-first lead of their external auditor and decided most of the IT general controls were key.
Reynolds knew that would result in detailed, across-the-board testing that could devour resources. She wanted to prioritize the core systems on which the finance team truly relied. Around the same time, working with a different client, she asked for a list of critical applications and was startled when she began reviewing it. “One of the applications that the finance team said they had been relying on for Sarbanes-Oxley didn’t even exist,” she says.
Reynolds’ experiences highlight a common internal audit dilemma. When technology is complex and ubiquitous, how can an audit shop maintain a focus on the important risks, and their business impact, without getting bogged down in detail? And how can it justify its decision to “ignore” some areas of IT risk in favor of others, especially if management or the external auditors want to see more testing done, or effort directed elsewhere?
In 2007, The IIA published a new methodology to help internal auditors respond to exactly this challenge. The Guide to the Assessment of IT General Controls Scope Based on Risk — known as GAIT (see “The Four GAIT Principles” at right) — sets out a process that auditors can use to identify the key risks in IT business processes. It also provides a way of working out how better IT general controls could mitigate those risks. Auditors can then use other methodologies and guidance, such as ISACA’s Control Objectives for Information and Related Technology (COBIT) or The IIA’s Global Technology Audit Guides, to decide which specific controls to deploy.
|
The Four GAIT Principles The GAIT Methodology sets out a structured process for identifying risks within IT business processes where a control or security failure could lead to a material error in the organization’s financial statements. If a failure is likely, the tool identifies the IT general control process risks in detail and the related IT general control objectives that, when achieved, mitigate these risks. COBIT and other methodologies then can be used to identify the key controls that address these IT general control objectives.
Although GAIT was originally developed for Sarbanes-Oxley compliance, GAIT For Business and IT Risk, known as GAIT-R, describes how companies not affected by Sarbanes-Oxley can apply the same four core GAIT principles:
IIA members can download the GAIT Methodology, GAIT-R, and other related tools and case studies from www.theiia.org/gait.
|
The GAIT process is “top down” and risk-based, meaning that it starts with a business process — rather than a specific IT application — and looks at the IT risks that could lead to failure or error in that process. It’s a structured way of focusing internal audit effort where it is most needed.
The IIA originally developed GAIT to help internal auditors deal with the kind of problem Reynolds faced — getting controls that were not considered key out of the scope of Sarbanes-Oxley testing. It has since produced a generic version — called GAIT-R — that allows auditors to apply the same core IT risk assessment principles and procedures to any situation. Like the original methodology, GAIT-R takes a top-down approach, but recognizes that auditors working in other types of organizations have their own needs to assess the IT risks related to business processes, such as ensuring the availability of IT services and the security of data that are important to operations. It starts by identifying business objectives for which controls are to be assessed and works through a series of steps culminating in determining the scope of the review and the design of a testing program.
Although the GAIT Methodology has been well-received by the internal auditors who have tried it, many auditors are concerned about whether they have the skills and knowledge needed to implement it. For two years running, an annual Protiviti survey of internal audit competencies found knowledge of GAIT was the area that respondents felt they most needed to improve. But Raj Chaudhary, principal in the Risk Consulting business unit of public accounting and consulting firm Crowe Horwath LLP in Oak Brook, Ill., who helps companies with IT risk assessments, says internal auditors shouldn’t be daunted. A methodology like GAIT focuses on “IT general controls,” such as who can access a database and what backup systems are in place, rather than detailed, application-specific controls, so it doesn’t require huge amounts of technical knowledge.
“It’s about understanding the level of risk you are taking as a business because you are depending on a particular technology,” he argues. “The level of knowledge you need — about the technology that the business process depends on — is not super technical. Internal auditors who are not savvy from a technical perspective should not have any trouble understanding the business process and the risks associated with it failing.”
Internal auditors who get to grips with GAIT will find it a powerful tool, says Fawn Taylor, a manager responsible for Sarbanes-Oxley controls and compliance at computer chip maker Intel in Hillsboro, Ore. She says that in its early years of Sarbanes-Oxley compliance Intel was very conservative in the number of controls it tested. “We were looking at how to take a risk-based approach so that we could focus on what was critical,” she explains.
Taylor heard that The IIA was developing something that might help, and got involved in the project to write GAIT, using Intel as a testing ground. Within three years GAIT had helped Intel cut the number of IT-related financial reporting controls it tested from more than 1,300 to a couple of hundred, which contributed to a 65 percent reduction in the company’s testing effort.
The big difference GAIT made was enabling the audit shop to talk about the likelihood of a risk occurring, Taylor says. Sarbanes-Oxley, by contrast, encouraged companies to test controls related to any IT system that could have an impact on the financial statements; it took little account of whether that impact was likely to occur. In those companies, even if the threat of a control failure was found to be remote, and its impact on the business small, once someone had decided that it needed to be tested the pressure was on to test it every subsequent year.
The GAIT Methodology gave Taylor the leverage to break that test-everything mind-set and apply a true risk-based approach. “GAIT was an embraced industry standard, so we could say to our colleagues, ‘This is what everyone else is doing, we could do this,’” she explains. “The effect was huge. Being able to point to something that The IIA was driving gave us so much power to challenge the status quo.”
Intel developed a simple way of categorizing its business applications, based on what Taylor calls their “proximity” to its financial statements. For those that are critical to the financial statements — such as those that post directly to the general ledger — all general controls are tested. For the remaining applications, Intel uses this decision-making approach alongside GAIT to determine the level of testing needed — all controls, some of them, or none at all.
Barry Hadfield helped several large organizations conduct IT risk assessments using GAIT before he joined UK financial firm Friends Provident as an IT audit manager last October. Hadfield says he valued GAIT because the methodology, and the documentation it generated, made it easier for the internal audit team to justify its risk assessments to the company’s external auditor. “GAIT provided a risk-based rationale for why we were testing particular areas and not others,” he says.
GAIT is not prescriptive and does not tell an internal auditor what risks to focus on; rather it helps them to work out what the core IT risks are for their specific organization, Hadfield stresses. “GAIT gives you a way of showing that you have thought about what you are doing and a way of justifying it,” he says.
Hadfield often encountered external audit firms and management that had fixed ideas about where and how IT reliance created financial statement risks. “We used GAIT to say that’s not where the risk comes from in this business,” he explains.
Reynolds used GAIT to build a more constructive relationship with the company’s external auditor when she directed the internal audit team at BusinessObjects, a software company now owned by SAP. After the internal audit team implemented GAIT, the external auditors decided to rely almost 100 percent on their work, Reynolds says -— to be precise, the firm retested just one control. “We reduced our IT key controls as well as the automated controls by more than 50 percent,” she says.
GAIT was developed to help internal auditors assess IT risks in a specific financial reporting compliance context — Sarbanes-Oxley — but its value is broader than that, say people who have used it. “GAIT is a best practice. It’s good for understanding your IT control environment,” Reynolds says. “The bottom line for us was that using GAIT really helped us to understand the business better.”
Taylor agrees. “The beauty of GAIT is that it offers a methodology for IT risk and control assessments covering any business process, not just financial reporting,” she says. Intel is now looking at using GAIT to assess IT risk more widely. “I don’t think GAIT is specific to Sarbanes-Oxley at all, and if people pigeonhole it there, they will completely limit the success they can have with it,” she stresses.
The key question that GAIT helps a business answer is this, Hadfield says: “Are we monitoring the right risks in the IT infrastructure?” He is currently looking at implementing GAIT for the first time at Friends Provident. “I want to know that we are auditing the right areas,” he says. “I want to get an understanding of what are the key applications and systems in use, how they hang together, and what the risks are.”
Although Chaudhary says general internal auditors should not be daunted by the prospect of using a methodology like GAIT to run an IT risk assessment, they will likely need specialist input at some stage. He uses the example of a key database that might not be able to handle a surge in online transaction volumes in a business that is growing rapidly. Taking a top-down approach, auditors at the company could use GAIT to identify the risk that a big increase in orders might cause a system to fail by asking, “What IT systems is that process reliant on?” “It’s not hard to identify a risk like that, but what’s tough is testing whether you have the controls in place to deal with an overload of the system,” he explains.
The level of testing needed to determine whether the application might actually fail, at what level of order volume a failure would occur, and what application controls are needed to mitigate a failure will probably require specialist skills, Chaudhary says. But there is danger that once such specific testing starts, the potential business consequences of any discovered control weaknesses are lost. “Technology guys are good at talking about what could happen,” he notes, but they often fail to explain the impact of a risk in business or financial terms. That, in turn, makes it harder for internal auditing to get someone to take whatever action is needed to deal with the risk.
His advice is to present the findings of a technology risk assessment in ways that the organization’s senior executives can understand. Rather than pointing to a lack of control over the way data is managed, talk about how those weaknesses create opportunities for a hacker to steal trade secrets and the impact that could have on the business.
“It’s a problem that you need to resolve from both ends,” Chaudhary says. IT specialists need to be able to talk about risks in terms that the business can understand, and the business needs to adopt and implement a common risk assessment methodology that IT people can use.
As powerful as GAIT is, the effort needed to use it fully shouldn’t be underestimated. Internal auditors who have implemented it say they had to produce large amounts of documentation and talk of a steep learning curve, at least at the beginning. “You can’t just take it and apply it; you have to think about what you are trying to achieve and take your own organizational context into account,” Hadfield says.
Then again, the benefits of using GAIT are considerable. Internal auditors have used it to slash the number of IT general controls they must test and reduced the need for — and cost of — double-checking by the external auditor. But GAIT is valuable in a wider business context too. It can help the internal audit shop in any business get a better understanding of a key risk area — IT usage. And as organizations become increasingly reliant on complex IT systems, that is a valuable understanding to have.
To comment on this article, e-mail the author at neil.baker@theiia.org.
Internal Auditor is pleased to provide you an opportunity to share your thoughts about the articles posted on this site. Some comments may be reprinted elsewhere, online, or offline. We encourage lively, open discussion and only ask that you refrain from personal comments and remarks that are off topic. Internal Auditor reserves the right to edit/remove comments.