Management, compliance & auditing

IT auditing and controls - An introduction

Auditing is an evaluation of a person, organization, system, process, enterprise, project or product, performed to ascertain the validity and reliability of information; and also to provide an assessment of a system's internal controls. The goal of an audit is to express an opinion based on the work done and since due to practical constraints, an audit provides only reasonable assurance that the statement are free from material error and typically rely on statistical sampling.

IT auditing takes that one step further and evaluates the controls around the information with respect to confidentiality, integrity, and availability. While a financial audit will attest to the validity and reliability of information, the IT audit will attest to the confidentiality of the information, the integrity of the information and in situations where availability is a key factor will also attest to the availability and the ability to recover in the event of an incident.

One of the key factors in IT auditing and one that audit management struggles with constantly, is to ensure that adequate IT audit resources are available to perform the IT audits. Unlike financial audits, IT audits are very knowledge intensive, for example, if an IT auditor is performing a Web Application audit, then they need to be trained in web applications; if they are doing an Oracle database audit, they need to be trained in Oracle; if they are doing a Windows operating system audit, they need to have some training in Windows and not just XP, they'll need exposure to Vista, Windows 7, Server 2003, Server 2008, IIS, SQL-Server, Exchange, etc.. As you can appreciate being an IT auditor requires extensive technical training in addition to the normal auditor and project management training.

Another factor that audit management faces is the actual management of the IT auditors, for not only must they track time against audit objectives, audit management must allow for time to follow-up on corrective actions taken by the client in response to previous findings and/or recommendations.

There are many different types of audits:

• Financial audits
• Operational audits
• Integrated audits
• Administrative audits
• IT audits
• Specialized audits
• Forensic audits

The IT auditor will be involved with all of these except the financial audit. And when we talk about extensive technical training and forensic IT auditing we are speaking about a significant investment in time and money for an IT auditor to be qualified to do a forensic IT audit.

Since there is a limited amount of time and a limited amount of professional qualified IT auditors, IT auditing is more and more moving to a risk-based audit approach which is usually adapted to develop and improve the continuous audit approach.

But before we get into risk, let's take a look (briefly) at IT audit's role within the organization. IT audit's role is to provide an opinion on the controls which are in place to provide confidentiality, integrity and availability for the organization's IT infrastructure and data which supports the organization's business processes. Now in order to do that there has to be some overall planning to determine which business processes to audit. I mentioned before that IT auditing is moving towards a risk-based audit approach and the planning process starts with a review of the organization and gaining an understanding of the business. Typically this starts with a review of the Business Impact Analysis (BIA) which the organization has prepared for all of its business functions, after which the organization will have established ranking criteria and determined which functions are essential to the business. Those essential functions will then have been ranked according to which ones are most critical to the organization and the IT auditor can start at the top of the list. Now granted there are a lot of other considerations which go into which functions to audit, including the last time an area was audited, are there legal requirements which require annual audit/compliance statements, etc., but for the time being starting at the top will assure management that the most critical business functions are being reviewed by IT audit. There are some other reasons to use risk assessment to determine the areas to be audited, including:

• Enables management to effectively allocate limited audit resources
• Ensures that relevant information has been obtained from all levels of management
• Establishes a basis for effectively managing the IT audit department/function
• Provides a summary of how the individual audit subject area is related to the overall organization as well as to the business plans.

Now for some definitions before we go any further:

• Audit risk – the risk that information may contain a material error that may go undetected during the course of the audit.
• Inherent risk – the risk that an error exists that could be material or significant when combined with other errors encountered during the audit, assuming that there are no related compensating controls. Inherent risks exist independent of an audit and can occur because of the nature of the business. (e.g. if you build your data center in the basement of the building, and the building is located in a flood plain, there is an inherent risk that your data center will get flooded.) I know bad example; who would do that, but it helps explain the idea.
• Control risk – the risk that a material error exists that will not be prevented or detected in a timely manner by the internal control systems. If for example, the internal control is a manual review of computer logs, errors might not be detected in a timely manner simply due to the volume of data in the computer logs.
• Detection risk – the risk that an IT auditor uses an inadequate test procedure and concludes that material errors do not exist when, in fact, they do. For example, let's say you're using the FREE version of a testing tool which does not contain all the vulnerability database entries and you conclude there are no errors in a particular database, when in fact, there are, which you would have found if you had been using an adequate test procedure. In this case, the full blown version of a testing tool and not a demo version.

Audit objectives refer to the specific goals that must be accomplished by the IT auditor, and in contrast, a control objective refers to how an internal control should function. Audit objectives most often, focus on substantiating that the internal controls exist to minimize business risks, and that they function as expected. As an example, in a financial audit, an internal control objective could be to ensure that financial transactions are posted properly to the General Ledger, whereas the IT audit objective will probably be extended to ensure that editing features are in place to detect erroneous data entry.

So what is a control or an internal control? Let's take a look at some examples. Internal controls are normally composed of policies, procedures, practices and organizational structures which are implemented to reduce risks to the organization. There are two key aspects that controls should address: that is, what should be achieved and what should be avoided. Controls are generally classified as either preventive, detective or corrective. So first, preventive; the controls should, detect problems before they arise such as a numeric edit check on a dollar data entry field. By not allowing anything other than numeric characters you are preventing things like cross-site scripting or SQL injection. Next detective controls; like exception reports from log files which show that an unauthorized user was attempting to access data outside of their job requirements. Then finally, corrective; something as simple as taking backups, so that in the event of a system failure, you can correct the problem by restoring the database. The backup procedures being the corrective control.

When you look at business functions, one of the things an IT auditor should look for is where in the process is there a potential for compromise of confidentiality, integrity or availability. For example, if data is gathered via a web front-end which is then reformatted and sent to the database either for storage or inquiry and then returned to the web front-end for redisplay to the user there a number of control points to consider:

• The web front-end itself, who has access and how are they authenticated
• The connection between the web front-end and the database, how is this connection protected
• The database, who is allowed to update, what data can be returned to the web front-end
• The network, is traffic restricted to just the traffic required to support the web application

The list goes on and on but you get the point, there are a lot of control points to consider when looking at a particular business function. In trying to determine all the control points, an IT auditor must consider the system boundary which should be part of the Business Impact Analysis we discussed earlier. And from that BIA, the IT auditor should be able to construct a data flow diagram and to identify all the control points that will need to be reviewed as part of his/her audit.

Remember, our work is resource intensive and we have a limited amount of time, so taking a risk based approach, we would review the control points that represent the greatest risk to the business. And it is part of our job to identify the risks and to help management understand what the risk to the business would be if a control at a specific point malfunctions and the information is compromised.

You can find other articles related it IT Auditing and Controls here.