Chapter 3: Introduction to Information Technology Audit

What is an Information Technology (IT) Audit?


✓IT audit is the examination and evaluation of an organization's information technology infrastructure,
policies and operations. Information technology audits determine whether IT controls protect corporate
assets, ensure data integrity and are aligned with the business's overall goals. IT auditors examine not
only physical security controls, but also overall business and financial controls that involve information
technology systems.

✓It can also be defined as any audit that encompasses review and evaluation of automated information
processing systems, related non-automated processes and the interfaces among them.

IT Audit Objectives
Because operations at modern companies are increasingly computerized, IT audits are used to ensure
information-related controls and processes are working properly. The primary objectives of an IT audit
include:
✓Evaluate the systems and processes in place that secure company data.

✓Determine risks to a company’s information assets, and help identify methods to minimize those
risks.

✓Substantiating that the internal controls exist and are functioning as expected to minimize business
risk.

✓Ensure information management processes are in compliance with IT-specific laws, policies and
standards.

✓Determine inefficiencies in IT systems and associated management.



BASIC COMPONENTS OF AN AUDIT

SYSTEMATIC PROCESS

Conducting an audit is a systematic and logical process that applies to all forms of information systems. While
important in all audit settings, a systematic approach is particularly important in the IT environment. The lack
of physical procedures that can be visually verified and evaluated injects a high degree of complexity into the
IT audit. Therefore, a logical framework for conducting an audit in the IT environment is critical to help the
auditor identify all-important processes and data files.

MANAGEMENT ASSERTIONS AND AUDIT OBJECTIVES

The organization’s financial statements reflect a set of management assertions about the financial health of
the entity. The task of the auditor is to determine whether the financial statements are fairly presented. To
accomplish this, the auditor establishes audit objectives, designs procedures, and gathers evidence that
corroborates or refutes management’s assertions. These assertions fall into five general categories:

1. Existence or Occurrence assertion - affirms that all assets and equities contained in the balance sheet exist
and that all transactions in the income statement actually occurred.

2. Completeness assertion - declares that no material assets, equities, or transactions have been omitted
from the financial statements.

3. Rights and Obligations - assertion maintains that assets appearing on the balance sheet are owned by the
entity and that the liabilities reported are obligations.

4. Valuation or Allocation assertion - states that assets and equities are valued in accordance with generally
accepted accounting principles and that allocated amounts such as depreciation expense are calculated on a
systematic and rational basis.

5. Presentation and Disclosure assertion - alleges that financial statement items are correctly classified (e.g.,
long-term liabilities will not mature within one year) and that footnote disclosures are adequate to avoid
misleading the users of financial statements.

Generally, auditors develop their audit objectives and design audit procedures based on the preceding
assertions.
Audit objectives may be classified into two general categories. The preceding assertions related to transactions
and account balances that directly impact financial reporting. The second category pertains to the information
system itself. This includes the audit objectives for assessing controls over manual operations and computer
technologies used in transaction processing.

OBTAINING EVIDENCE

Auditors seek evidential matter that corroborates management assertions. In the IT environment, this process
involves gathering evidence relating to the reliability of computer controls as well as the contents of databases
that have been processes by computer programs. Evidence is collected by performing tests of controls, which
establish whether internal controls are functioning properly, and substantive tests, which determine whether
accounting databases fairly reflect the organization’s transactions and account balances.

ASCERTAINING MATERIALITY

The auditor must determine whether weaknesses in internal controls and misstatements found in transactions
and account balances are material. In all audit environments, assessing materiality is an auditor judgment. In
an IT environment, however, this decision is complicated further by technology and a sophisticated internal
control structure.

COMMUNICATING RESULTS

Auditors must communicate the results of their tests to interested users. An independent auditor renders a
report to the audit committee of the board of directors or stockholders of a company. The audit report
contains, among other things, an audit opinion. This opinion is distributed along with the financial report to
interested parties both internal and external to the organization. IT auditors often communicate their findings
to internal and external auditors, who can then integrate these findings with the non-IT aspects of the audit.
IT Audit vs. Financial Statement Audit and Compliance Audit

IT Audit is not about ordinary accounting controls or traditional financial auditing. The use of computers
in accounting systems introduced a new source of risk associated with accounting processes and
information (i.e., data). And, it introduced the need for those who understand this new “thing” to identify
and mitigate the risk. Financial Audit is focused on gathering data to ensure that the company’s financial
statements are free from material misstatements. On the other hand, IT audit is the examination and
evaluation of an organization's information technology infrastructure, policies and operations.
Information technology audits determine whether IT controls protect corporate assets, ensure data
integrity and are aligned with the business's overall goals. IT Audit is just a part of the overarching process
of the Financial Audit.

IT auditing is also not compliance testing. Some believe IT auditors are about making sure people conform
to some set of rules—implicit or explicit—and that what we do is report on exceptions to the rules.
Actually, that is management’s job. It is not the compliance with rules that is of interest to IT auditors. IT
auditors are examining whether the entity’s relevant systems or business processes for achieving and
monitoring compliance are effective. IT auditors also assess the design effectiveness of the rules—
whether they are suitably designed or sufficient in scope to properly mitigate the target risk or meet the
intended objective.

Compliance failures are important to IT auditors, but for reasons beyond the keeping of rules. A
compliance failure can be, and often is, the symptom of a bigger problem related to some risk factor
and/or control, such as a defective system or business process, that can or does adversely affect the entity.
Thus, to the IT auditor, compliance failures are much more about risk (ultimately) than the rules
themselves.

It is also passé to automatically or casually consider IT considerations of an audit to be out of scope

because it is not explicitly related to some stated requirement, or to consider an audit to be a waste of
time. The fact is IT can and does adversely affect business processes or financial data in ways of which
management may not be adequately aware.

IT Audit Process

1. Planning the Audit Schedule

A key part of a good process is having an overall Audit Schedule that is readily available to let everyone
know when each process will be audited over the upcoming cycle (usually a yearly schedule). If you were
not to have a plan and went with surprise audits, the message that is given from senior management is
“We don’t trust our employees.” By publishing the audit intentions, the message is that this is meant as a
support to the process owners and the auditors are there to help. This can allow the process owners to
time the finish of any improvement projects that they are working on to be before the audit, so that they
can gather valuable information on the implementation, or to request the auditors to focus on helping to
gather information for other planned improvements.

2. Planning the Process Audit

The first step in planning the individual process audits is to confirm with the process owners when the
audit will take place. The overall plan above is more of a guideline as to how often processes will be
audited, and roughly when, but the confirmation allows the auditor and process owner to collaborate to
determine the best time to review the process. This is when the auditor can review previous audits to see
if any follow-up is required on comments or concerns previously found, and when the process owner can
identify any areas that the auditor can look at to assist the process owner to identify information. A good
audit plan can make sure that the process owner will get value out of the audit process.

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:
a. Knowledge of business and industry
b. Prior year’s audit results
c. Recent financial information
d. Regulatory statutes
e. 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:
a. Control Environment
b. Control Procedures
c. Detection Risk Assessment
d. Control Risk Assessment
e. 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.
3. Conducting the Audit

An audit should start with a meeting of the process owner to make sure that the audit plan is
complete and ready. Then there are many avenues for the auditor to gather information during
the audit: reviewing records, talking to employees, analyzing key process data or even observing
the process in action. The focus of this activity is to gather evidence that the process is functioning
as planned in the QMS, and is effective in producing the required results. One of the most
valuable things that an auditor can do for a process owner is not only to identify areas that do not
have evidence that they are functioning properly, but also to point out areas of a process that may
function better if changes are made.

4. Reporting on the Audit

A closing meeting with the process owner is a necessity to ensure that the flow of information is not
delayed. The process owner will want to know if there are any areas of weakness that need to be
addressed, but will also be interested in knowing if any areas exist that might be improved. This should
be followed with a written record as soon as possible to provide the information in a more permanent
format to enable follow-up of the information. By identifying not only the non-conforming areas of the
process, but also the positive areas and potential improvement areas, the process owner will get a better
value from the Internal Audit, which will allow for process improvements.

5. Follow-up on Issues or Improvements Found

As with many areas of the standard, follow-up is a critical step. If problems have been found and corrective
actions taken, making sure that the problem is actually fixed is a key part of fixing it. If improvement
projects have been completed from opportunities identified in the audit, then seeing how much the
process has improved is a great motivator for future improvements.

Overview of the Four (4) Phases of an IT Audit

The IT audit is generally divided into three phases: audit planning, tests of controls, and substantive
testing.

1. Audit Planning

The first step in the IT audit is audit planning. Before the auditor can determine the nature and extent of
the tests to perform, he or she must gain a business. A major part of this phase of the audit is the analysis
of audit risk. The objective of the auditor is to obtain sufficient information about the firm to plan the
other phases of the audit. The risk analysis incorporates an overview of the organization’s internal
controls. During the review of controls, the auditor attempts to understand the organization’s policies,
practices, and structure. In this phase of the audit, the auditor also identifies the financial attempts to
understand the controls over the primary transactions that are processed by these applications.
The techniques for gathering evidence at this phase include questionnaires, interviewing management,
reviewing systems documentation, and observing activities. During this process, the IT auditor must
identify the principal exposures and the controls that attempt to reduce these exposures. Having done so,
the auditor proceeds to the next phase, where he or she tests t controls for compliance with pre-
established standards.

2. Tests of Controls

The objective of the tests of controls phase is to determine whether adequate internal controls are in
place and functioning properly. To accomplish this, the auditor performs various tests of controls. The
evidence gathering techniques used in this phase may include both manual techniques and specialized
computer audit techniques.

At the conclusion of the tests controls phase, the auditor must assess the quality of internal controls. The
degree of reliance the auditor can ascribe to internal controls affects the nature and extent of substantive
testing that needs to be performed.

3. Substantive Testing

The third phase of the audit process focuses on financial data. This involves a detailed investigation of
specific account balances and transactions through what are called substantive tests. For example, a
customer confirmation is a substantive test sometimes used to verify account balances. The auditor
selects a sample of accounts receivable balances and traces these back to their source – the customers-
to determine if the amount stated is in fact owed by a bona fide customer. By doing so, the auditor can
verify the accuracy of each account in the sample. Based on such sample findings, the auditor is able to
draw conclusions about the fair value of the entire accounts receivable asset.

Some substantive tests are physical, labor-intensive activities such as counting cash, counting inventories
in the warehouse, and verifying the existence of stock certificates in a safe. In an IT environment, the
information needed to perform substantive tests (such as account balances and names and addresses of
individual customers) is contained in data files that often must be extracted using Computer Assisted Audit
Tools and Techniques (CAATTs) software.

4. Audit Report

So what’s included in the audit documentation and what does the IT auditor need to do once their audit
is finished. Here’s 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 organization’s 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.