You are on page 1of 8

So you want to be an IT Auditor..

Over the course of the next few weeks, I will be posting some ten articles to help you understand what
it takes to move from wherever you are to a job as an IT Auditor:

Well start with an Introduction to IT Auditing;

Move on to the Planning that goes into an IT Audit;

Then well look at several of the different auditing organizations, their standards, and their

In the fourth article well start looking at IT Governance, what it is, and why its important.

Following that will some articles on

IT Basics,

The Internet,

General Controls,

Application Controls,

Database Controls

And well wrap it all up with some IT infrastructure controls.

Being an IT auditor doesnt just mean going in and looking to see if the organization has policies and
procedures. Sure it includes that. But that is just the organization saying WHAT theyre going to
do. IT Auditors will take that information and ask questions like, Did you do what it says here in this
procedure?; Can you prove that you did what it says in this procedure?; and Was the control you
put in place, effective?; and then follow that with the question, Can you prove that it was effective?

Say what you do,

Do it,

Prove that you did it, and then

Prove that it was effective.

Over the course of these articles, well also talk about some specific controls that you as an IT auditor
will want to look for and well meld that into Industry Best Practices. Ill also introduce you to some of
my favorite tools, which I use when doing audits. And maybe, youll be able to ask the same questions
of your clients. If you know the IT auditor is going to do a readability test of your backup media, why
arent you doing it before the IT auditor gets here? One would think that if you as a client knew what
the auditors were going to be looking for, you would do whatever you needed to do, so that all the
answers were correct and supported.
Hopefully, at the end of these articles you will have an appreciation of IT auditing and you will be able
to go into an organization, perform an audit, and add value to the business process.
Introduction to IT Audit
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 systems 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, theyll 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, lets take a look (briefly) at IT audits role within the organization. IT audits
role is to provide an opinion on the controls which are in place to provide confidentiality, integrity and
availability for the organizations IT infrastructure and data which supports the organizations 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,

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, lets say youre 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? Lets 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.
Definition of IT audit An IT audit can be defined as any audit that encompasses review and evaluation
of automated information processing systems, related non-automated processes and the interfaces
among them. Planning the IT audit involves two major steps. The first step is to gather information
and do some planning the second step is to gain an understanding of the existing internal control
structure. More and more organizations are moving to a risk-based audit approach which is used to
assess risk and helps an IT auditor make the decision as to whether to perform compliance testing or
substantive testing. In a risk-based approach, IT auditors are relying on internal and operational
controls as well as the knowledge of the company or the business. This type of risk assessment
decision can help relate the cost-benefit analysis of the control to the known risk. In the Gathering
Information step the IT auditor needs to identify five items:

Knowledge of business and industry

Prior years audit results

Recent financial information

Regulatory statutes

Inherent risk assessments

A side note on Inherent risks, is to define it as the risk that an error exists that could be material or
significant when combined with other errors encountered during the audit, assuming there are no
related compensating controls. As an example, complex database updates are more likely to be

miswritten than simple ones, and thumb drives are more likely to be stolen (misappropriated) than
blade servers in a server cabinet. Inherent risks exist independent of the audit and can occur because
of the nature of the business.
In the Gain an Understanding of the Existing Internal Control Structure step, the IT auditor needs to
identify five other areas/items:

Control environment

Control procedures

Detection risk assessment

Control risk assessment

Equate total risk

Once the IT auditor has Gathered Information and Understands the Control then they are ready to
begin the planning, or selection of areas, to be audited. Remember one of the key pieces of information
that you will need in the initial steps is a current Business Impact Analysis (BIA), to assist you in
selecting the application which support the most critical or sensitive business functions.

Objectives of an IT audit
Most often, IT audit objectives concentrate on substantiating that the internal controls exist and are
functioning as expected to minimize business risk. These audit objectives include assuring
compliance with legal and regulatory requirements, as well as the confidentiality, integrity, and
availability (CIA no not the federal agency, but information security) of information systems and

IT audit strategies
There are two areas to talk about here, the first is whether to do compliance or substantive testing and
the second is How do I go about getting the evidence to allow me to audit the application and make
my report to management? So what is the difference between compliance and substantive
testing? Compliance testing is gathering evidence to test to see if an organization is following its
control procedures. On the other hand substantive testing is gathering evidence to evaluate the
integrity of individual data and other information. For example, compliance testing of controls can be
described with the following example. An organization has a control procedure which states that all
application changes must go through change control. As an IT auditor you might take the current
running configuration of a router as well as a copy of the -1 generation of the configuration file for the
same router, run a file compare to see what the differences were; and then take those differences and
look for supporting change control documentation. Dont be surprised to find that network admins,
when they are simply re-sequencing rules, forget to put the change through change control. For
substantive testing, lets say that an organization has policy/procedure concerning backup tapes at
the offsite storage location which includes 3 generations (grandfather, father, son). An IT auditor
would do a physical inventory of the tapes at the offsite storage location and compare that inventory
to the organizations inventory as well as looking to ensure that all 3 generations were present.

The second area deals with How do I go about getting the evidence to allow me to audit the application
and make my report to management? It should come as no surprise that you need to:

Review IT organizational structure

Review IT policies and procedures

Review IT standards

Review IT documentation

Review the organizations BIA

Interview the appropriate personnel

Observe the processes and employee performance

Examination, which incorporates by necessity, the testing of controls, and therefore includes
the results of the tests.

As additional commentary of gathering evidence, observation of what an individual actually does

versus what they are supposed to do, can provide the IT auditor with valuable evidence when it comes
to control implementation and understanding by the user. Also performing a walk-through can give
valuable insight as to how a particular function is being performed.

Application vs. general controls

General controls apply to all areas of the organization including the IT infrastructure and support
services. Some examples of general controls are:

Internal accounting controls

Operational controls

Administrative controls

Organizational security policies and procedures

Overall policies for the design and use of adequate documents and records

Procedures and practices to ensure adequate safeguards over access

Physical and logical security policies for all data centers and IT resources

Application controls refer to the transactions and data relating to each computer-based application
system; therefore, they are specific to each application. The objectives of application controls are to
ensure the completeness and accuracy of the records and the validity of the entries made to
them. Application controls are controls over IPO (input, processing, output) functions, and include
methods for ensuring that:

Only complete, accurate and valid data are entered and updated in an application system

Processing accomplishes the designed and correct task

The processing results meet expectations

Data is maintained

As an IT auditor, your tasks when performing an application control audit should include:

Identifying the significant application components; the flow of transactions through the
application (system); and to gain a detailed understanding of the application by reviewing all
available documentation and interviewing the appropriate personnel, such as system owner,
data owner, data custodian and system administrator.

Identifying the application control strengths and evaluating the impact, if any, of weaknesses
you find in the application controls

Developing a testing strategy

Testing the controls to ensure their functionality and effectiveness

Evaluating your test results and any other audit evidence to determine if the control objectives
were achieved

Evaluating the application against managements objectives for the system to ensure
efficiency and effectiveness.

IT audit control reviews

After gathering all the evidence the IT auditor will review it to determine if the operations audited are
well controlled and effective. Now this is where your subjective judgment and experience come into
play. For example, you might find a weakness in one area which is compensated for by a very strong
control in another adjacent area. It is your responsibility as an IT auditor to report both of these findings
in your audit report.

The audit deliverable

So whats included in the audit documentation and what does the IT auditor need to do once their
audit is finished. Heres the laundry list of what should be included in your audit documentation:

Planning and preparation of the audit scope and objectives

Description and/or walkthroughs on the scoped audit area

Audit program

Audit steps performed and audit evidence gathered

Whether services of other auditors and experts were used and their contributions

Audit findings, conclusions and recommendations

Audit documentation relation with document identification and dates (your cross-reference of
evidence to audit step)

A copy of the report issued as a result of the audit work

Evidence of audit supervisory review

When you communicate the audit results to the organization it will typically be done at an exit interview
where you will have the opportunity to discuss with management any findings and
recommendations. You need to be absolutely certain of:

The facts presented in the report are correct

The recommendations are realistic and cost-effective, or alternatives have been negotiated
with the organizations management

The recommended implementation dates will be agreed to for the recommendations you have
in your report.

Your presentation at this exit interview will include a high-level executive summary (as Sgt. Friday use
to say, just the facts please, just the facts). And for whatever reason, a picture is worth a thousand
words so do some PowerPoint slides or graphics in your report.

Your audit report should be structured so that it includes:

An introduction (executive summary)

The findings are in a separate section and grouped by intended recipient

Your overall conclusion and opinion on the adequacy of controls examined and any identified
potential risks

Any reservations or qualifications with respect to the audit

Detailed findings and recommendations

Finally, there are a few other considerations which you need to be cognizant of when preparing and
presenting your final report. Who is the audience? If the report is going to the audit committee, they
may not need to see the minutia that goes into the local business unit report. You will need to identify
the organizational, professional and governmental criteria applied such as GAO-Yellow Book, CobiT
or NIST SP 800-53. Your report will want to be timely so as to encourage prompt corrective action.
And as a final, final parting comment, if during the course of an IT audit, you come across a materially
significant finding, it should be communicated to management immediately, not at the end of the audit.