The Role of the IT Audit Team

So isn't this a book about IT auditing? So far, most of what you've read in this chapter is pretty much applicable to any sort of auditing. While this is true, the concepts we've discussed thus far are foundational to building an effective internal audit team, whether it's focused on IT auditing or another sort.

So let's talk about IT auditing. What is it? The obvious answer is that it's the auditing of information technology, computer systems, and the like. We'll assume that if you're reading this book, you understand the basic difference between an IT auditor and a financial or operational auditor, so let's not belabor the point by coming up with a technical definition of IT auditing. However, there are a number of variations and interpretations as to the role of an IT audit group within the overall audit function. We'll look at a few models:

1. Information systems auditors

2. Support for the financial auditors

3. IT auditors

Before exploring what these mean, let's define a greatly simplified basic stack of potential technical subject areas that an IT audit group might be called on to review (Figure 1-2):

Figure 1-2: Potential auditing subject areas.

1. Entity-level controls. These are controls that are pervasive across the organization and provide the basic foundation for the control environment at the company. Examples of standard entity-level controls are company policies and mechanisms for complying with regulations such as Sarbanes-Oxley and the Health Insurance Portability and Accountability Act (HIPPA).

2. Physical facility. This, quite simply, is the physical building and data center housing the computer equipment on which the system in question resides.

3. Networking and communications infrastructure. This is what allows other systems and users to communicate with the system in question when they do not have physical access to it. This layer includes basic networking devices such as firewalls, switches, and routers.

4. Operating system. This is what provides the basic operating environment on which the higher-level application runs. Examples are Unix, Linux, and Windows.

5. Middleware. This is software that provides additional integration between two separate "programs" that were not originally designed to communicate with each other (e.g., between a database system and a web server or between an application and a database that it was not originally designed to access).

6. Database. This is the tool that organizes and provides access to the data being run by the end application.

7. Application. This is the end application, which actually is seen and accessed by the end user. This could be an enterprise resource planning (ERP) application providing basic business functions, an e-mail application, or a system that allows conference rooms to be scheduled.

Some element of all these generally will be relevant to all systems reviewed. The majority of this book is dedicated to detailing exactly how to audit these areas (and others), so we won't spend time on that here. However, it is important to understand that these layers work together and that each forms a foundation for the next layer.

Note 

This is not intended to be an exhaustive list of potential subject areas and technologies that could be reviewed by an IT auditor. It is instead intended to illustrate some of the more common layers that might be reviewed during an audit. The stack of potential auditing subject areas could be made significantly more complex and granular if desired, spiking out topics such as storage and web servers. However, this simplified version will help illustrate the following discussion regarding types of IT auditors.

With this as a background, let's look again at those models of IT auditing mentioned earlier that describe the role of an IT audit group within the overall audit function.

Information Systems Auditors

There are an amazing number of IT audit groups that really aren't IT audit groups at all. These groups generally contain no true IT auditors but instead are made up of business or financial folks who know how to use business application systems. These audit teams focus almost solely on the application layer. They do a very thorough job of ensuring that access is properly controlled and that segregation of duties issues does not exist. They likely will do a good job of ensuring that unauthorized changes to the application cannot occur and that good controls are in place to ensure the integrity of data being entered into the system. However, they miss most or all of the other layers, meaning that they are only seeing part of the picture. They are not reviewing the foundational controls on which all systems rely, such as the security of the network and of the operating system environment. If those areas are not controlled properly, it's like locking the door but leaving the windows open. There are multiple ways for people to exploit security weaknesses at those other layers to disrupt the integrity, reliability, and security of the application systems. IT audit groups usually take this approach when they have not hired people with the appropriate technical skill sets that would allow them to understand and review the other layers of the stack. They focus on the application layer because that is all they understand.

Support for Financial Auditors

Still other IT audit groups spend the majority of their time pulling data for the financial auditors and helping them analyze it. They are likely to be experts at data extraction and analysis tools, such as Audit Command Language (ACL), but are not truly auditors. They receive requirements from the financial auditors and execute those requirements. For example, the financial audit team may be reviewing an accounts receivable process and asks the IT auditors to pull a list of all invoices greater than 90 days past due. These types of auditors can be a valuable part of an audit department, but if they constitute your entire IT audit function, you're missing a lot of the risk.

IT Auditors

Other departments have IT auditors that spend the majority of their time focusing on areas beneath the application layer in the stack. They ensure that the core infrastructure supporting the company's systems has the proper security and controls. These audit teams generally consist of IT professionals, as opposed to business folks who understand how to use application systems. The database layer and below constitute the domain of these IT auditors, and application audits are driven by the financial auditors with support provided by the IT auditors as needed. For example, the IT auditors might look at the database layer and below as they apply to that specific application (assuming that those items haven't been covered previously in larger-scale audits of the IT environment). In addition, the IT auditors might help to review some of the general application controls, such as change controls and overall system access administration. However, the financial auditors should have the knowledge and be in a better position to understand what sorts of data integrity controls and segregation of duties are necessary for that particular business application.

Note 

The third model (IT auditors) seems to be the most thorough and effective because it ensures that all layers are being covered and that they are being covered by the people with the highest level of subject matter knowledge.

Some companies have developed a mix of the three models, and that also can be very successful. The key is that companies need some IT auditing that goes beyond the application layer in order to truly perform the function successfully.