Chapter 3 Otero

Chapter 3
The IT Audit Process
LEARNING OBJECTIVES
1.Describe what audit universe is, and illustrate example.
2.Define control objectives for information and related technology and explain why
they are useful for organizations and auditors.
3.Explain what a risk assessment is and its significance to the audit function.
Illustrate an example of a risk assessment following the National Institute of
Standards and Technology methodology.
4.Describe an audit plan and its components. Illustrate examples of IT audit
documentation supporting a financial statement audit.
5.Define the audit process and describe the phases of an IT audit engagement.
6.Discuss other types of audits conducted in IT.
The role of IT audit continues to be a critical mechanism for ensuring the

integrity of information systems and the reporting of organization finances to
prevent future financial fiascos such as Enron (2001) and WorldCom (2002).
Unfortunately, these fiascos continue to occur. Global economies are more
interdependent than ever and geopolitical risks impact everyone. Electronic
infrastructure and commerce are integrated in business processes around the globe.
The need to control and audit IT has never been greater.
Today's IT auditor is faced with many concerns about the exposure of
information systems to a multitude of risks. From these concerns arise the
objectives for the audit process and function. This chapter looks at the audit
process for IT and the demands that will be placed on the profession in the future.
Audit Universe
One of the best practices for an audit function is to have an audit universe. The
audit universe is aninventory of all the potential audit areas within an
organization. Basic functional audit areas within an organization include sales,
marketing, customer service, operations, research and development, finance, human
resource, information technology, and legal. An audit universe documents the key
business processes and risks of an organization. Documenting processes and,
particularly, risks have proved to be a best practice for organizations. The IIA’s
Performance Standard 2010 encoutages the establishment of risk-based plans to
determine the priorities for internal audit activity.
An audit universe includes the basic functional audit area, organization
objectives, key business processes that support those organization objectives,
specific audit objectives, risks of not achieving those objectives, and controls
that mitigate the risks. Tying the audit universe to organizational objectives
links the entire audit process to business objectives and risks, making it easier
to communicate the impact of control deficiencies. Exhibit 3.1 shows an example of
an audit universe related to the IT area of an organization.
59
60 ®m [nformation Technology Control and Audit
The audit universe is also an essential building block to a properly risk-

based internal audit process. Typically, internal audit groups prepare annual audit
schedules to determine the number of hours available and the number of audits that
can be performed. The audit universe is an ongoing process; as an organization
changes, new risks arise or existing risks change, and new regulations are
introduced. Organizations can either remove lower-priority audits from the schedule
or hire external auditors to supplement internal staff.
IT audits, for example, have specific IT processes to include in the audit
universe. Control Objectives for Information and Related Technology (COBIT)
provides a comprehensive list of critical I'T processes, which can be used as a
starting point.
COBIT
COBIT is an authoritative, international set of generally accepted IT practices or
control objectives that help employees, managers, executives, and auditors in:
understanding IT systems, discharging fiduciary responsibilities, and deciding
adequate levels of security and controls.
COBIT supports the need to research, develop, publicize, and promote up-to-
date internationally accepted IT control objectives. The primary emphasis of the
COBIT framework issued by Information Systems Audit and Control Foundation in 1996
is to ensure that technology provides businesses with relevant, timely, and quality
information for decision-making purposes. The COBIT framework, now on its fifth
edition (COBIT 5), has evolved over the years and each time there are major changes
to the framework, the framework is numbered to its current version.
The benefit of a standard framework for IT controls, such as COBIT, is that it
allows management to benchmark its environment and compare it to other
organizations. IT auditors can also use COBIT to substantiate their internal
control assessments and opinions. Because the framework is comprehensive, it
provides assurances that IT security and controls exist.
COBIT 5, which can be downloaded from www.isaca.org, helps organizations
create optimal value from IT by maintaining a balance between realizing benefits
and optimizing risk levels and resource use. COBIT 5 is based on five principles
(see Exhibit 3.2). COBIT 5 considers the I'T needs of internal and external
stakeholders (Principle 1), while fully covering the organization’s governance and
management of information and related technology (Principle 2). COBIT 5 provides an
integrated framework that aligns and integrates easily with other frameworks (e.g.,
Committee of
Sponsoring Organizations of the Treadway Commission-Enterprise Risk Management
(COSO-
ERM), etc), standards, and best practices used (Principle 3). COBIT 5 enables IT to
be governed and managed in a holistic manner for the entire organization (Principle
4) through:
a. Establishing principles, policies, and practical guidance for daily management.

b. Implementing processes to achieve overall IT-related goals and objectives.
Exhibit 3.1 Example of an Audit Universe Related to the IT Area of an Organization
Basic Functional Audit Area: Information Technology

Organization's Objective: To provide secure access to financial information,
technology, and services for all authorized employees.
Key Business Process IT Audit Objective IT Risk IT Mitigating Control
Access Control Management System's security is appropriately implemented,
administered, and logged to safeguard against unauthorized access to or
modifications of programs and data, that result in incomplete, inaccurate, or
invalid processing or recording of financial information. Users possess privileges
that are not consistent with their job functions,thus allowing unauthorized or
incorrect modifications to financial or accounting data, which could cause
segregation of duties conflicts, unprevented or undetected errors,
incorrect financials, or management decisions based upon misleading information.
User access privileges are periodically reviewed by application owners to
verify access privileges remain appropriate and consistent with job requirements.
Change Control Management Programs and systems are appropriately implemented in

a manner supporting the accurate, complete, and valid processing and recording of
financial information. Developers or programmers have the ability to promote
incorrect or inappropriate modifications or changes to financial data, programs, or
settings into the production processing environment, thus resulting in invalid
accounting data and/or fraud. Application systems,databases, networks, and
operating systems are developed, modified,and tested in an environment separate
from the production environment. Access to the development and test environments is
appropriately restricted.
Management of Data Center, Network, and Support Data are appropriately managed to
provide reasonable assurance that financial data remain complete, accurate, and
valid throughout the update and storage process. Financial reporting
information and accounting data cannot be recovered in the event of system failure,
impacting the entity's ability to report financial information according to
established reporting requirements.
Backups are archived off-site to minimize risk that data are lost.
62 Bm [nformation Technology Control and Audit
Exhibit 3.2 Principles of the COBIT 5 framework. (Adapted from

http://www.isaca.org/cobit/pages/cobit-5-framework-product-page.aspx.)
c. Putting in place organizational structures with key decision-making

capabilities.
d. Promoting good culture, ethics, and behavior in the organization.
e. Recognizing that information is pervasive throughout any organization, and often
the key product of the organization itself.
f. Taking into account the infrastructure, technology, and applications that
provide the organization with IT processing and services.
g. Recognizing that people, skills, and competencies are required for successful
completion of all activities and correct-decision making,
COBIT 5 assists organizations in adequately separating governance from management

objectives (Principle 5). Both governance and management are described below.
a. Governance—optimizes the use of organizational resources to effectively address

risks. Governance ensures that the Board of Directors (“board”):
i. evaluates stakeholder needs to identify objectives,
ii. guides management by prioritizing objectives, and
iii. monitors overall managements performance.
b. Management—oplan, build, run, and monitor the activities and processes used by
the organization to pursue the objectives established by the board.
COBIT 5s framework is valuable for all size types organizations, including
commercial, not-for-profit, or in the public sector. The comprehensive framework
provides a set of control objectives that not only helps IT management and
governance professionals manage their IT operations, but also IT auditors in their
quests for examining those objectives.
The COBIT processes can be customized to the organization’s environment. IT
auditors can help audit management identify the applications associated with the
critical business and financial processes, as well as controls that are necessary
to make the area being audited free from significant exposures to risk. This
objective also encompasses validating adherence of the application systems under
examination to appropriate standards (e.g., financial accounting should conform to
GAAP, etc.).
The IT Audit Process ® 63
The next step in the planning process is to perform a risk assessment for each
universe item from Exhibit 3.1. The risk assessment will analyze exposures and help
prioritize “high risk” audit projects.
Risk Assessment
Risk assessments are considered the foundation of the audit function as they assist
in developing
the process for planning individual audits. Specifically, risk assessments:
improve the quality, quantity, and accessibility of planning data, such as risk
areas, past audits and results, and budget information;
examine potential audit projects in the audit universe and choose those that have
the greatest risk exposure to be performed first; and
provide a framework for allocating audit resources to achieve maximum benefits.
Given the high number of potential audits that can be performed and often the
limited
amount of audit resources, it is important to focus on the right audits. The risk
assessment approach provides explicit criteria for systematically evaluating and
selecting these audits.
In today’s environment, it is difficult to keep pace with organization and
regulatory changes to provide timely information on internal controls. Change
increases the audit universe, the number of business partners (i.e., vendors), and
the number of projects where an objective and independent perspective is needed. An
effective risk assessment planning process allows auditing to be more flexible and
efficient to meet the needs of a changing organization, such as:
identifying new risk areas

identifying changes in existing risk areas
accessing current regulatory and legal information
taking advantage of information gathered during the audit process to improve risk
assessment
Audit areas can be evaluated using a weighted scoring mechanism. However, audit
management must evaluate the results using their knowledge of the organization
objectives and environment to make sure the priorities reflect reality. Audit areas
may also be grouped to improve audit efficiency when reviewing similar processes.
The auditing function is cyclical in that it uses historical and current
information for risk assessment, evaluates controls, communicates results, and
incorporates those results back into the risk assessment.
In an IT risk assessment, for instance, financial applications are common
audits/projects to be ranked. Their risks can be identified, assessed, and
prioritized. Controls (safeguards) are also identified to be put in place to
address and mitigate such risks. IT risks surrounding financial applications can be
identified through:
Audits, reviews, inspections
Reading flowcharts of operations
Using risk analysis questionnaires
Analyzing financial statement trends
Completing insurance policy checklists
64 m [nformation Technology Control and Audit
Absolute security from threads and risks in today’s technology environments is

unrealistic. Risk assessments, according to the National Institute of Standards and
Technology (NIST) Special Publication 800-30, ate used to assist organizations
determine the extent of potential threats and the risks associated with IT systems
and applications. The results of the above assist management in identifying and
implementing appropriate IT controls for reducing or eliminating those threats and
risks during the mitigation process. NIST recommends that for a risk assessment, it
is important that organizations follow these steps:
1. Have a process in place to identify or characterize assets (e.g., financial
applications, etc.).
2. Define vulnerabilities on those assets and the threat-sources that can trigger
them.
3. Determine the likelihood or probability levels (e.g., very high, high, medium,
etc.) that vulnerabilities may be exercised. For example, probabilities of very
high = 1.00, high = 0.75, medium = 0.50, low = 0.25, and very low = 0.10 may be
assigned for each vulnerability based on the organization’ estimate of their
likelihood level.
4. Assign a magnitude of impact to determine how sensitive the asset may be against
successfully exercised threats. Magnitudes of impact and impact level values are
typically assigned by management for every successful threat that may exercise a
vulnerability.
5. Associate assets with correspondent I'T and/or business risks.
6. Compute risk rating by multiplying the probability assigned from Step 3 above
(e.g.,
1.00, 0.75, etc.) times the impact level value assigned in Step 4.
7. Recommend the controls that are needed to mitigate the risks according to their
priority or ranking,
It is up to the organization to determine how to deal with the risks they have
identified: take a chance and live with them or take action to protect their
assets. At the same time, they must consider the costs associated with implementing
controls, their impact on users, the manpower required to implement and manage
them, and the scope of the action. Exhibit 3.3 shows an example of an IT risk
assessment performed to identify and prioritize risks within financial
applications. Risk assessment is covered in more detail in a later chapter.
Audit Plan
The audit function should formulate both long-range and annual plans. Planning is a
basic function necessary to describe what must be accomplished, include budgets of
time and costs, and state priorities according to organizational goals and
policies. The objective of audit planning is to optimize the use of audit
resources. To effectively allocate audit resources, internal audit departments must
obtain a comprehensive understanding of the audit universe and the risks associated
with each universe item. Failure to select appropriate items can result in missed
opportunities to enhance controls and operational efficiencies. Internal audit
departments that develop and maintain audit universe files provide themselves with
a solid framework for audit planning.
The intent of the audit plan is to provide an overall approach within which
audit engagements can be conducted. It provides the guidance for auditing the
organizations integral processes.
Exhibit 3.3 Risk Assessment Example for the IT Functional Audit Area
Likelihood Determination Impact
Impact
Financial IT Area / Likelihood | Probability | Magnitude | Level Risk Recommended
Action
Application Vulnerability | Threat-Source Level Assigned of Impact | Value Risk
Rating? Control Priority
Financial IS Operations/ | Hurricanes, Medium 0.50 High 75 [FA1 information 37.5 |

Backups of FA1 Medium
Application | There is no system cannot be financial data are
#1 (FAT) offsite storage failures, recovered in archived off-site
for data unexpected the event of to minimize risk
backups to shutdowns system failure, that data are lost.

provide impacting the
reasonable Company’s
assurance of ability to report
availability in financial
the event of a information
disaster. according to
established
reporting
requirements.
Information Unauthorized | High 0.75 High 75 [Security 56.25 | The identity of

users | High
Security / users parameters is authenticated to
Several of the (hackers, are not FA1 through
Company's terminated appropriately passwords
logical security | employees, configured, consistent with
settings (i.e., and insiders) allowing for industry best
passwords) potential practices minimum
configured for unauthorized security values.
FA1 are not user access Passwords must

consistent with to FA1. incorporate
industry best configuration for
practices. minimum length,
periodic change,
password history,
lockout threshold,
and complexity.
(Continued)
The IT Audit Process BB 65
Exhibit 3.3 (Continued) Risk Assessment Example for the IT Functional Audit Area
Financial
Application
IT Area /
Vulnerability
Threat-Source
Likelihood Determination
Impact
Likelihood
Level
Probability
Assigned
Magnitude
of Impact
Impact
Level
Value
Risk
Risk
Rating?
Action
Priority
Recommended
Control
Financial
Application
#2 (FA2)
Information
Security / FA2
owners do not
periodically
review user
access
privileges.
Unauthorized
users
(hackers,
terminated
employees,
and insiders)
Very High
1.00
High
75
Users possess
privileges that
are not
consistent with
their job
functions,
allowing
unauthorized
or incorrect
modifications
to FA2's data,
which could
cause
management
decisions
based upon
misleading
information.
75
User access
privileges within
FA2 are
periodically
reviewed by
application
owners to verify
access privileges
remain
appropriate and
consistent with
job requirements.
Very
High
Information
Security /
Terminated
user accounts
are not
removed from
FA2.
Unauthorized
users
(terminated
employees)
Very High
1.00
High
75
Terminated
users can gain
access to FA2
and view or
modify its
financial
information.
75
The security
administrator is
notified of
employees who
have been
terminated. Access
privileges of such
employees are
immediately
changed to reflect
their new status.
Very
High
(Continued)
66 ® Information Technology Control and Audit
Exhibit 3.3 (Continued) Risk Assessment Example for the IT Functional Audit Area
Likelihood Determination Impact
IT Area /
Vulnerability
Likelihood
Level
Financial
Application
Probability
Assigned
Magnitude
Threat-Source of Impact
Impact
Level
Value
Risk
Risk
Rating?
Recommended
Control
Action
Priority
Change Control
Management /
Test results for
FA2 upgrades
are not
approved by
management,
prior to their
implementation
into
production.
application
changes and
modifications
Unauthorized | Low 0.25 High 75
FA2 changes are

not properly
authorized.
Implementation
of such changes
could result in
invalid or
misleading data.
18.75
Changes to FA2 are
tested and
approved by
management prior
to their
implementation in
production in
accordance with
test plans and
results.
Low
2 Computed by multiplying the “Probability Assigned” and the “Impact Level Value.”
The IT Audit Process B® 67
The organization and its management must participate in and support this effort
fully. Commitment can be gained if participants recognize that a good plan can help
pinpoint problems in a highly dynamic, automated IT environment, for instance.
Thus, it should be the responsibility of all participants not only to help pinpoint
such problems, but also to assist in the measurement and quantification of
problems.
Identifying, measuring, and quantifying problems in the IT area are difficult.
The IT field is technologically complex and has a language of its own. Participants
in the formulation of an IT audit plan, and particularly the IT auditors
themselves, must have sufficient experience and training in technical matters to be
able to grasp key concepts and abstractions about application systems. For example,
abstractions about IT might include significant aspects that are susceptible to
naming, counting, or conceptualizing. Understanding the systems at this level can
lead to the identification of major problem areas. Audit concentration, then, may
be directed to the major problem areas most likely to yield significant results.
Based on this identification of problems, the IT auditor determines what
additional data might be required to reach evaluation decisions. The audit process,
therefore, must be flexible enough to combine skilled personnel, new technology,
and audit techniques in new ways to suit each situation. However, this flexibility
of approach requires documentation in planned, directed steps. Systems that are
understood poorly (or that have been designed without adequate controls) can result
in lost revenues, increased costs, and perhaps disaster or fraud.
During the audit planning phase, the IT audit manager should meet with the
chief information officer (CIO) and senior members of IT management to gain their
input and concurrence with the risk assessment of the I'T processes in the audit
universe. If there is an IT steering committee, the audit universe should be
reviewed with it as well. This will help ensure alignment between IT, business, and
audit on the key risk areas. The meeting with the CIO and IT managers must also
introduce the audit staff and communicate the scope, objectives, schedule, budget,
and communication process to be used throughout the engagement. This is also an
opportunity for an open discussion of IT management's perception of risk areas,
significant changes in the area under review, and identification of appropriate
contacts in IT.
An IT audit plan partitions the audit into discrete segments that describe
application systems as a series of manageable audit engagements and steps. At the
detailed planning or engagement level, these segments will have objectives that are
custom-tailored to implement organizational goals and objectives within the
circumstances of the audit. Thus, IT auditing does not call for “canned”
approaches. There is no single series of detailed steps that can be outlined once
and then repeated in every audit. The audit plan, therefore, is an attempt to
provide an orderly approach within which flexibility can be exercised. At a
minimum, an IT audit plan, after gathering a comprehensive understanding of the
audit universe and the risks associated with each universe item, should:
1. List the audit objectives and describe the context

2. Develop the audit schedule
3. Create the audit budget and define scope
4. List audit team members, describe audit tasks, determine deadlines
The IT Audit Process BB 69
Objectives and Context

The objective and context of the work are key elements in any audit environment and
should not be overlooked. They are simply the basis by which all audits should be
approached. The objective is what is trying to be accomplished. The context is the
environment in which the work will be performed. Thus, everything ultimately
depends on both the objective and the context of the work to be performed. That is,
the decisions made about the scope, nature, and timing of the audit work depends on
what the auditor’s trying to do (e.g, gain assurance of an Accounts Receivable
balance, ensure that a newly-implemented financial application will work correctly,
assess whether a client Website is secure, etc.) and the environment he/she is
working in (e.g., a large versus a small company, a domestic organization with a
centralized system versus a multinational with multiple divisions, a New York-based
organization versus one based in North Dakota, etc.).
Keep in mind what works well for one organization, may not work as well in
another based on many combinations of objective and context. For example, if the IT
auditor has a General Controls Assessment, the audit objectives may be to verify
that all controls surrounding financial applications and related to the data
center, information systems operations, information security, and change control
management are adequate. Therefore, the IT auditor needs to verify the controls
because the financial auditors were relying on such financial computer system to
provide them with
the correct financial information. The context is where the auditor's true
analytical skills come into play. Here, the environment is for the most part always
different from shop to shop. The auditor must assess the context for which he or
she has entered and make a decision as to how the environment should be addressed
(e.g., big company, small company, large staff, small staff, etc.).
By defining appropriate objectives and context of the work, management can
ensure that the audit will verify the correct functioning and control of all key
audit areas. A common objective/context set for IT audits is to support financial
statement audits.
IT Audits Conducted to Support Financial Statement Audits

Once the auditor has gained a general familiarity with the client’s accounting and
financial procedures, specific areas of audit interest must be identified. The
auditor must decide what applications will have to be examined at a more detailed
level. For applications used to support significant business processes, the auditor
must determine their sophistication and extent of use. This preliminary study goes
just deep enough for the auditor to evaluate the complexity and sophistication of
the applications and determine the procedures to be followed in evaluating their
internal controls.
Understanding financial applications and determining whether IT controls are
in place to effectively secure them and the information generated represent a
significant process as it relates to the overall financial statement audit. Results
of an IT audit over financial applications have direct bearing on the substantive
testing performed by financial auditors. Substantive testing involves audit
procedures necessary to examine and support the financial statements (e.g.,
confirming account balances, examining documentation, re-performing procedures,
inquiring about or observing a transaction, etc.). These procedures provide the
evidence needed to support the assertion that financial records of the organization
are indeed valid, accurate, and complete.
The results or findings from an IT audit typically determine the amount of
substantive tests that will be performed by financial auditors. If results are
effective (i.e., IT controls are found to be in place and operating properly), the
work of the financial auditor would most likely be less on that particular part of
the audit. On the other hand, if there are no IT controls in place protecting the
financial applications, or if existing IT controls are not operating effectively,
the amount of substantive testing performed by the financial auditor will be much
higher. This can have significant implications to the audit, such as the time it
takes to complete the audit, increased costs to the client, etc. The remainder of
this chapter is focused on IT audits conducted to support financial statement
audits. The next step within the audit plan is the development of an audit
schedule.
70 ® [nformation Technology Control and Audit

Audit Schedule
Internal auditing departments create annual audit schedules to gain agreement from
the board on audit areas, communicate audit areas with the functional departments,
and create a project/resource plan for the year. The audit schedule should be
linked to current business objectives and risks based on their relative cost in
terms of potential loss of goodwill, loss of revenue, or noncompliance with laws
and regulations.
Annual schedule creation is the process of determining the total audit hours
available, then
assigning universe items (audit areas) to fill the available time. As mentioned
previously, to maximize the risk assessment process, “high risk” universe items
should be given top audit priority. Schedule creation should be performed in
conjunction with the annual risk assessment process;this will enable internal audit
departments to account for the changes in risk rankings and make any necessary
additions or deletions to the audit universe. Of course, the audit schedule will
also need to be agreed with the audit committee as part of the overall audit
planning process. Once the available audit hours are determined, audit management
can continue preparing the audit plan.
Planning and scheduling are ongoing tasks as risks, priorities, available
resources, and timelines change. When these changes take place, it is important to
communicate them to the audit committee, board, and all other impacted functional
departments.
Audit Budget and Scoping

Ideally, the audit budget should be created after the audit schedule is
determined. However, most organizations have budget and resource constraints. An
alternative approach may be necessary when building the audit schedule. After
determining the audit priorities, audit management will determine the number of
available hours to decide how many audits they can complete in a year. For a
particular IT audit, available hours are listed per area, staff personnel, etc.
Exhibit 3.4 illustrates an example of a budget in an IT audit.
The scope of an audit defines the area(s) (e.g, relevant financial
applications, databases, operating systems, networks, etc.) to be reviewed. The
names of the financial applications and databases should also be described along
with their hosting information (e.g., server location, etc.). The scope should
clearly identify the critical business process supported by the selected financial
application. This association typically justifies the relevance of the application
and, hence, its inclusion as part of the audit. The scope should further state the
general control areas, control objectives,and control activities that would undergo
review. Exhibit 3.5a, b shows examples of scoping for applications and control
objectives, respectively, in an IT audi.
Audit Team, Tasks, and Deadlines

The audit plan must include a section listing the members of the audit, their
titles and positions,
and the general tasks they will have. For instance, a typical audit involves staff
members, seniors, managers, or senior managers, and a partner, principal, or
director (PPD) who will be overseeing the entire audit. At a staff level (usually
those auditors with less than 3 years of experience), most of the field work is
performed, including gathering documentation, meeting with personnel, and creating
audit work papers, among others. Senior-level auditors not only supervise the work
of staff auditors, but guide them in performing the work (e.g., accompany staff
auditors to meet with users, assist the staff in selecting what specific
information should be gathered, how to document such information in the working
papers, etc.). Next are the managers or senior managers (senior managers are
typically involved as part of large audits) that supervise the audit work prepared
by the staff and reviewed by the senior.
The IT Audit Process m 71
Exhibit 3.4 Example of a Budget for an IT Audit
Company Name
IT Budget
Fiscal Year 20XX
Audit Professional
Staff/ Total
Audit Area Senior | Manager Partner Hours
Planning
Review work papers from the prior 3.0 1.0 0.0 4.0
year, if applicable; prepare IT budget;
conduct planning meetings; prepare
planning memo; prepare initial
request of information and send to
company personnel, etc.
First year. Gather and document an 3.0 1.0 0.0 4.0

understanding of the organization and
its IT environment, including how the
organization utilizes computer system
and which applications impact critical
business/financial processes, among
others.
Subsequent years. Review and update

the understanding of the organization
and its IT environment obtained from
the prior year.
Conduct planning meeting with 1.0 1.0 1.0 3.0

company personnel.
Subtotal 7.0 3.0 1.0 11.0 11%
Fieldwork
Document/update understanding of
the organization's IT environment and
perform tests of IT controls (per
General Control IT area).
Information Systems Operations 16.0 0.0 0.0 16.0
Information Security 17.0 0.0 0.0 17.0
Change Control Management 20.0 0.0 0.0 20.0
Subtotal 53.0 0.0 0.0 53.0 53%
(Continued)
72m [nformation Technology Control and Audit
Exhibit 3.4 (Continued) Example of a Budget for an IT Audit
Company Name
IT Budget
Fiscal Year 20XX
Audit Professional
Staff/ Total
Audit Area Senior | Manager Partner Hours
Review, Reporting, and Conclusion
Review and document action(s) taken 2.0 0.0 0.0 2.0
by company’s Management to correct
last year’s IT audit findings/
deficiencies.
Document IT audit findings/ 3.0 0.0 0.0 3.0
deficiencies and opportunities to
improve existing controls.
Assess and classify identified IT audit 1.0 0.0 0.0 1.0
findings/deficiencies.
Draft IT Management letter listing all IT 0.0 1.0 1.0 2.0
audit findings/deficiencies and
opportunities to improve existing
controls. Forward letter to IT
Management for review.
Conduct status meetings, internally or 1.0 0.0 0.0 1.0
with IT personnel.
Review work papers evidencing 0.0 9.0 4.0 13.0
IT audit work performed.
Exit meeting with IT personnel to 0.0 1.0 0.0 1.0
discuss audit and results.
Address and clear review notes from 11.0 2.0 0.0 13.0
audit management (Manager and
Partner) and conclude audit.
Subtotal 18.0 13.0 5.0 36.0 | 36%
Grand Total 78.0 16.0 6.0 100.0 | 100%
Staff/Senior 78.0 78%
Manager 160 | 16%
Partner 6.0 6%
Exhibit 3.5a Example of Scoping for Financial Applications
Company Name
Financial Applications and their Association with Business Processes
Fiscal Year 20XX
Purpose: To identify relevant applications by mapping them to their corresponding

business process(es). An “X” in the table on the right identifies the business
process supported by the application. For example, the SAP application is used by
(or supports) the Financial Reporting, Expenditures, Inventory Management,
and Revenue business processes. This association typically justifies the relevance
of the application and, hence, its inclusion as part of the audit.
Business Process Supported
Application
Brief
Description
Processing
Environment
(Operating
System
Where the
Application
Is Installed
On)
Physical
Hosting
Location—
Application
and Database
Database
Management
Software
Financial Payroll & | Inventory

Reporting | Expenditures | Personnel| Management | Investment
Fixed
Revenue | Assets
1(SAP
Includes the
general
ledger,
expenditures,
inventory
management,
and revenue
accounting
modules.
UNIX Oracle Local Data X X X X

Center,
Second Floor;
Company's
Headquarters
[location]
oN
Infinium
Manages the
payroll.
AS/400 Oracle Local Data X

Center,
Second Floor;
Company's
Headquarters
[location]
(Continued)
Exhibit 3.5a (Continued) Example of Scoping for Financial Applications
Company Name
Financial Applications and their Association with Business Processes
Fiscal Year 20XX
Purpose: To identify relevant applications by mapping them to their corresponding

business process(es). An "X" in the table on the right identifies the business
process supported by the application. For example, the SAP application is used by
(or supports) the Financial Reporting, Expenditures, Inventory Management,
and Revenue business processes. This association typically justifies the relevance
of the application and, hence, its inclusion as part of the audit.
Business Process Supported
H*
Application
Brief
Description
Processing
Environment
(Operating
System
Where the
Application
Is Installed
On)
Physical
Hosting
Location—
Application
and Database
Database
Management
Software
Financial Payroll & | Inventory

Reporting | Expenditures | Personnel | Management | Investment
Fixed
Revenue | Assets
3|APS/2
Manages
investments.
Windows Oracle Local Data X

Center,
Second Floor;
Company's
Headquarters
[location]
Timberline
Manages long
term and
fixed assets.
Windows Oracle Local Data X

Center,
Second Floor;
Company's
Headquarters
[location]
74 Wm Information Technology Control and Audit
Exhibit 3.5b Example of Scoping for General Computer Control Objectives and
Activities
Company Name
General Computer Controls Objectives and Activities Selected
Fiscal Year 20XX
# IT Area Control Objective Control Activity
1 [Information [ISO 1.00 - IT operations 1SO 1.01 - Batch and/or online processing
is
Systems support adequate defined, timely executed, and monitored
Operations scheduling, execution, for successful completion.
monitoring, and continuity | 1SO 1.02 - Exceptions identified on batch
of systems, programs, and and/or online processing are timely
processes to ensure the reviewed and corrected to ensure
complete, accurate, and valid | accurate, complete, and authorized
processing and recording of | processing of financial information.
financial transactions.
2 |Information [ISO 2.00 - The storage of 1SO 2.02 - Automated backup tools have
Systems financial information is been implemented to manage retention
Operations appropriately managed, data plans and schedules.
accurate, and complete. 1SO 2.04 - Tests for the readability of

backups are performed on a periodic
basis. Results support timely and
successful restoration of backed up data.
3 |Information [ISO 3.00 - Physical access is |1SO 3.02 - Physical access is

authorized,
Systems appropriately managed to monitored, and restricted to individuals
Operations safeguard relevant who require such access to perform their
components of the IT job duties. Entry of unauthorized

infrastructure and the personnel is supervised and logged. The
integrity of financial log is maintained and regularly reviewed
information. by IT management.
4 |Information |ISEC 1.00 - Security ISEC 1.02 - Formal policies and procedures
Security configuration of define the organization's information
applications, databases, security objectives and the responsibilities

networks, and operating of employees with respect to the protection
systems is adequately and disclosure of informational resources.
managed to protect against | Management monitors compliance with
unauthorized changes to security policies and procedures, and
programs and data that may | agreement to these are evidenced by the
result in incomplete, signature of employees.
inaccurate, or invalid ISEC 1.06 - Consistent with information
processing or recording of | security policies and procedures, local and
financial information. remote users are required to authenticate
to applications, databases, networks, and
operating systems via passwords to
enhance computer security.
(Continued)
76 Wm [nformation Technology Control and Audit
Exhibit 3.5b (Continued) Example of Scoping for General Computer Control

Objectives and Activities
Company Name
Fiscal Year 20XX

5 |Information [ISEC 2.00 - Adequate security | ISEC 2.02 - System owners authorize
user
Security is implemented to protect | accounts and the nature and extent of
against unauthorized their access privileges.
access and modifications of | ISEC 2.04 - Users who have changed roles or
systems and information, tasks within the organization, or that have
which may result in the been transferred, or terminated are
processing or recording of | immediately informed to the security
incomplete, inaccurate, or department for user account access
invalid financial revision in order to reflect the new and/or

information. revised status.
ISEC 2.05 - Transmission of sensitive

information is encrypted consistent with
security policies and procedures to protect
its confidentiality.
6 | Change CCM 1.00 - Changes CCM 1.03 - Documentation related to the

Control implemented in change implementation is adequate and
Management | applications, databases, complete.
networks, and operating CCM 1.05 - Documentation related to the

systems (altogether change implementation has been released
referred to as “system and communicated to system users.
changes”) are assessed for
risk, authorized, and
thoroughly documented to
ensure desired results are
adequate.
7 | Change CCM 2.00 - Changes CCM 2.01 - System changes are tested
Control implemented in before implementation into the
Management | applications, databases, production environment consistent with
networks, and operating test plans and cases.
systems (altogether referred | CCM 2.02 - Test plans and cases involving
to as “system changes”) are | complete and representative test data
appropriately tested. Tests (instead of production data) are approved
are performed by a group by application owners and development
other than the group management.
responsible for the system
(e.g., operating systems
changes are implemented
by someone other than the
systems programmer, etc.).

(Continued)
The IT Audit Process Bm 77
Exhibit 3.5b (Continued) Example of Scoping for General Computer Control

Objectives and Activities
Company Name
Fiscal Year 20XX
8 [Change CCM 3.00 - Changes CCM 3.01 - Problems and errors

Control implemented in encountered during the testing of system
Management | applications, databases, changes are identified, corrected, retested,
networks, and operating followed up for correction, and

systems (altogether documented.
referred to as “system
changes”) are appropriately
managed to reduce
disruptions, unauthorized
alterations, and errors
which impact the accuracy,
completeness, and valid
processing and recording
of financial information.
9 [Change CCM 4.00 - Changes CCM 4.04 - An overall review is performed

Control implemented in by management after system changes have
Management | applications, databases, been implemented in the live or
networks, and operating production environment to determine

systems (altogether whether the objectives for implementing
referred to as “system system changes were met.
changes”) are formally
approved to support
accurate, complete, and
valid processing and
recording of financial
information.
Managers perform detailed reviews of the work papers and ensure the audit
objectives have been achieved. Managers meet frequently with audit clients, and
provide them with audit status, preliminary findings identified, hours incurred and
left to finish,etc. Managers also provide frequent status of the audit work to the
PPD assigned, to which they report directly. Lastly, the PPD performs a high-level
review of the work (as provided by managers), focusing on high-risk areas, controls
in place that are not adequately designed nor operating effectively, findings
identified and their impact to the overall audit, etc. PPDs tend to rely on the
detailed reviews performed by managers or senior managers, and also ensure the
overall objectives of the audit have been achieved.
Deadlines are a critical component of an audit plan. They should be reviewed
and agreed with
the client organization from the start of the audit so that they comply with
requirements established by third parties (e.g., banks, financial institutions,
etc.) and regulators (e.g., government,private organizations, etc.). Deadlines
should be well-thought of taking into account the information and resources that
must be available to perform the audit work within the established requirements.
An audit planning memo (“planning memo”) is part of the auditor working papers
and documents the sections just described. The planning memo is typically prepared
by the audit engagement senior, and reviewed by the manager before submitting it to
the PPD for approval.Appendix 1 shows the format of a typical IT planning memo,
including the procedures which may be performed by an IT auditor in connection with
an audit engagement. The planning memo may be tailored for the specific facts and
circumstances of the audit engagement. This includes removing sections which are
not applicable. The memo in Appendix 1 includes some wording in italics that is
either enclosed within brackets or parentheses. This format is used to indicate
information to be replaced as applicable, or that guides the completion of the
memo.
Audit Process
Statement on Auditing Standards (SAS No. 1) has the effect of mandating a uniform,
process-oriented approach to audit engagements. The approach depicted is a true
process technique. That is, audits follow a series of logical, orderly steps, each
designed to accomplish specific end results.
This is also the case for an IT audit. The difference in an I'T audit is the
specialized approach to the audit work and the skills needed to understand
technology and the IT control environment. The phases of auditing activities
typically ovetlap and involve some reassessment and retracing of procedures
performed earlier. Common phases of an audit engagement are shown in Exhibit 3.6.
The first two phases, Risk Assessment and Audit Plan, have been explained above.
Following are
explanations of the remaining phases related to an IT audit.
Preliminary Review
In this phase, the auditor should obtain and review summary-level information and
evaluate it in relation to the audit objectives. The purpose of the preliminary
review phase of an IT audit engagement is to gather an understanding of the I'T
environment, including the controls in place that are essential to meet the overall
audit objectives. The IT auditor conducts this preliminary
review at a general level, without examining details of individual applications and
the processes
involved. Instead, the IT auditor interviews key personnel to determine policies
and practices, and prepares supplemental audit information as required. Preliminary
review information serves as a basis for supporting the information included in the
IT audit plan.
1. Risk assessment
8. Communication 2. Audit plan

7. Document 3. Preliminary
results review
6. Substantive 4. Design audit
testing procedures
5. Test controls
Exhibit 3.6 Phases of an audit.
General Information about IT Environment

As previously discussed, IT is defined as the hardware, software, communication,
and other facilities used to input, store, process, transmit, and output data in
whatever form. The IT environment refers to the policies, procedures, and practices
implemented by organizations to program, test, deliver, monitor, control, and
support their I'T infrastructure (e.g., hardware, software, networks, etc.). The IT
environment also includes the applications and programs used by
organizations to support critical business operations (i.e., financial operations)
and achieve business strategies.
The IT auditor begins the examination process by becoming acquainted,
generally, with the company, its line of business, and the IT environment,
including its financial application systems. Typically, an IT auditor would tour
the client company’s facilities and observe general business operations that bear
upon customer service as well as on strictly financial functions.
Given this familiarity, the next level of general data gathering would include
the preparation of organizational charts, particularly those for the accounting and
IT functions. If organizational charts are unavailable, the IT auditor should
develop them. Once drawn, the charts should be reviewed and verified with
appropriate personnel (i.e., key executives in the accounting and IT areas) to
secure an agreement that they represent the actual organization structure. During
these interviews, the IT auditor would also secure copies of the company’s chart of
accounts and an accounting standards manual, if available.
IT auditors must gain a deep understanding of the IT environment, particularly
how the organization responds to risks arising from IT, and whether the IT controls
in place have been adequately designed and operate effectively to address those
risks. From a financial standpoint, knowledge about the I'T environment is crucial
for I'T auditors in order to understand how financial transactions are initiated,
authorized, recorded, processed, and reported in the financial statements.
For application systems which the organization uses computers to process
significant financial data, the IT auditor would gather a number of specific items
of evidential matter, such as:
Policies and procedures that the organization implements and the IT infrastructure
and application software that it uses to support business operations and achieve
business strategies.
Narratives or overview flowcharts of the financial applications, including server
names, make and model, supporting operating systems, databases, and physical
locations, among others.
Whether the financial applications are in-house developed, purchased with little
or no customization, purchased with significant customization, or proprietary
provided by a service organization.
Whether service organizations host financial applications and if so, what are
these applications and which relevant services they perform.
Controls in place supporting the area of information systems operations, such as
those supporting job scheduling, data and restoration, backups, and offsite
storage.
Controls in place supporting the area of information security, such as those
supporting authentication techniques (i.e., passwords), new access or termination
procedures, use of firewalls and how are they configured, physical security, etc.
Controls in place supporting the area of change control management, such as those
supporting the implementation of changes into applications, operating systems, and
databases; testing whether access of programmers is adequate; etc.
80 m /nformation Technology Control and Audit
Methods applied in gathering these data include reviewing computer information

systems and human interface practices, procedures, documents, narratives,
flowcharts, and record layouts. Other audit procedures implemented to gather data
include: observing, interviewing, inspecting existing documentation, and
flowcharting, among others. Physical inspection techniques are used both to gather
data and to validate existing documents or representations made during the
interviews. For example, a single visit to the computer/data center can provide
both data gathering and validation opportunities for determining equipment
configurations, library procedures, operating procedures, physical security
controls, existing environmental controls, and other data control procedures.
Many of these procedures are substantially the same regardless of whether the
accounting system is computerized or not. Differences associated with the audit of
computerized systems center around changes in controls, documentation, audit
techniques, and technical qualifications required by audit staff members. Appendix
2 shows an example of the types of questions and information that should be
documented when gathering an understanding of an IT environment.
Design Audit Procedures

In this phase, the I'T auditor must prepare an audit program for the areas
being audited, select control objectives applicable to each area, and identify
procedures or activities to assess such objectives. An audit program differs from
an internal control questionnaire (ICQ) in that an ICQ involves questions to
evaluate the design of the internal control system. Particularly, ICQs check
whether controls are implemented to detect, prevent, or correct 2 material
misstatement. Controls not in place would represent a deviation or deficiency in
the internal control structure. An audit program, on the other hand, contains
specific procedures to test the responses received from the questions asked, thus
substantiating that the controls identified are in place and work as expected by
management.
An audit program is a formal plan for reviewing and testing each significant
audit subject area disclosed during fact gathering. The auditor should select
subject areas for testing that have a significant impact on the control of the
application and those that are within the scope defined by the audit objectives. IT
audit areas are very specific to the type of audit. For IT, COBIT is an excellent
starting point as it lists risks, objectives, and key controls per IT audit area.
This information then has to be customized to the particular organization
objectives, processes, and technology. Appendix 3 illustrates examples of IT Audit
Programs for the general control IT areas.
Identifying Financial Applications

With the help of management, the IT auditor must decide what application systems
will have to
be examined at a more detailed level (i.e., scoping). As a basis for preparation of
the audit plan, the IT auditor must also determine, in general, how much time will
be required, what types of people and skills will be needed to conduct the
examination; and, roughly, what the schedule will be.
The identification of financial applications can be accomplished with the
auditor gaining familiarity with the organization's accounting procedures and
processes. The importance of determining the significant financial applications has
to be derived through preliminary analysis. The assessment of the sophistication of
the application, its complexity, the business process they
support, and extent of use are factors that come into play in deciding whether to
select such application and how one might evaluate it. As stated before, the
preliminary review phase is a critical step in the audit process that examines an
organization's financial systems and provides the auditor with a basis for
selecting audit areas for more detailed analysis and evaluation whether they are
manual or computerized.
Auditors involved in reviewing financial applications should focus their concerns

on the applications control aspects. This requires their involvement from the time
a transaction is initiated until it is posted into the organization’s general
ledger. Specifically, auditors must ensure that provisions are made for:
An adequate audit trail so that transactions can be traced forward and backward
through the financial application
The documentation and existence of controls over the accounting for all data
(e.g., transactions, etc.) entered into the application and controls to ensure
the integrity of those transactions throughout the computerized segment of the
application
Handling exceptions to, and rejections from, the financial application
Unit and integrated testing, with controls in place to determine whether the
applications perform as stated
Controls over changes to the application to determine whether the proper
authorization has been given and documented
Authorization procedures for application system overrides and documentation of
those processes
Determining whether organization and government policies and procedures are
adhered to in system implementation
Training user personnel in the operation of the financial application
Developing detailed evaluation criteria so that it is possible to determine
whether the implemented application has met predetermined specifications
Adequate controls between interconnected application systems
Adequate security procedures to protect the user's data
Backup and recovery procedures for the operation of the application and assurance
of business continuity
Ensuring technology provided by different vendors (i.e., operational platforms) is
compatible and controlled
Adequately designed and controlled databases to ensure that common definitions of
data are used throughout the organization, redundancy is eliminated or controlled,
and data existing in multiple databases is updated concurrently
This list affirms that the IT auditor is primarily concerned with adequate controls
to safeguard the organization’s assets.
Test Controls
The IT auditor executes several procedures in order to test controls, processes,
and apparent exposures. These audit procedures may include examining documentary
evidence, as well as performing corroborating interviews, inspections, and personal
observations.
Documentary evidence may consist of a variety of forms of documentation on the
application system under review. Examples include notes from meetings on subject
system, programmer notes, systems documentation, screenshots, user manuals, and
change control documentation from any system or operation changes since inception,
and a copy of the contract if third parties involved. Examining such documentary
evidence may require the I'T auditor to ask questions of the user, developer and
managers to help him or her establish the appropriate test criteria to be used. It
also helps in identifying the critical application and processes to be tested.
Corroborating interviews are also part of the testing process, and may include
procedures such as:
Asking different personnel the same question and comparing their answers
Asking the same question in different ways at different times
Comparing answers to supporting documentation, work papers, programs, tests, or
other verifiable results
Comparing answers to observations and actual system results
An example would involve interviewing a programmer for an application under review.

The programmer states that the application has undergone recent changes not
reflected in the current documentation. It is very important to identify what those
changes were if those areas of the application were to be selected for control
testing.
For inspection of documentation, the IT auditor can obtain the logical
settings (i.e., passwords) currently configured at the organizations network,
operating system, and financial application levels. Of particular importance is to
obtain and assess the network’s configured logical settings as this is the first
level of authentication before users can gain access to the financial applications.
The settings received are then compared against the organizations password policy
to determine whether they are or not in compliance with such policies. In the
absence of a password policy, the organizations logical settings configured are
compared against industry standards or best practices. Documentation supporting the
above settings is usually first obtained through interviewing information security
personnel.
Another common audit procedure to test and validate information would be to observe
actual procedures taking place. In the example above, the IT auditor would observe
the settings configured in the financial application and request organization
personnel to print out a screenshot for documentation in the audit working papers.
Exhibit 3.7a shows an example of common documentation obtained supporting the
password settings configured. In this case, settings such as enforced password
history, minimum (or maximum) password age, minimum password length, password
complexity, account lockout duration and threshold, and whether passwords have been
stored using reversible encryption are some of the setting that are typically
gathered. An IT auditor working paper documenting testing of some of these settings
would look like the one in Exhibit 3.7b. Notice on the table the actual password
settings configured documented at the network (or the first authentication level),
operating system, and financial applications levels. Also notice notes and
tickmarks (explanations) about the information therein and, most importantly, the
assessment of whether the client password settings comply with either the existing
company policy, or industry standards and best practices. When settings do not
comply with the policy or industry standards or best practices, audit exceptions
(findings) are written up and listed in a separate working paper. This working
paper will eventually assist when writing up the findings/ deficiency section of
the Management Letter. A second example of observation as a test procedure would
involve an IT auditor examining a disaster recovery exercise. Here, the IT auditor
could determine whether personnel followed appropriate procedures and processes.
Through personal observations, the auditor can assess and determine whether
personnel is following operating procedures and plans, and is adequately prepared
for the disaster simulated.
"Fi Group Policy Object Editor
| Eile Action View Help

«= | E@E|x BD mE
Policy + [ Policy Setting

= Computer Configuration Enforce password history 0 passwords remembered
=] Software Settings #8] Maximum password age o

== Software installation Minimum password age 0 days
=) J Windows Settings fH] Minimum password length 4 characters

g Scripts (Startup/Shutdown) (#g]Password must meet complexity requirements
Disabled
B-@# Securky Settings [#8]Store passwords using reversible encryption Disabled
= 29 Account Policies
Account Lockout Policy

[2% Kerberos Policy
(#-£¢f Local Policies
[+ Event Log
#-_8 Restricted Groups
[1-8 System Services
#-_& Registry
#8 File System
Wireless Network (IEEE 802.11) Policies
[#1 Public Key Policies
#1] Software Restriction Policies
= Ee) IP Security Policies on Active Directory
=] Administrative Templates
= £8 User Configuration
#1 Software Settings
1-1 Windows Settings
2]
[#+/__] Administrative Templates
"Hii Group Palicy Object Editor
File Action View Help
Policy / | Policy setting

E(B) Computer Configuration Account lockout duration Mok Defined
Ba Software Settings 8) account lockout threshold invalid logon attempts
2 (1 Windows Settings [R¥]Reset account lockout counter after Mot Defined
cm
Scripts (Startup/Shutdown)
[=H Security Settings
3 Account Policies
4 Password Policy
Account Loc
SA
Exhibit 3.7a Example of evidence supporting logical security (password) settings

currently
implemented.
Substantive Testing
Where controls are determined not to be effective, substantive testing may be
required to determine whether there is a material issue with the resulting
financial information. In an IT audit, substantive testing is used to determine the
accuracy and completeness of information being generated by a process or
application. Contrary to compliance testing where the auditor’s goal is to confirm
whether the organization is adhering to applicable policies, procedures, rules, and
regulations. An example of a compliance test procedure would be verifying that a
change or upgrade in a financial application was adequately tested, approved, and
documented prior to its implementation.
Exhibit 3.7b Example Supporting a Logical Security Settings Test
Logical Setting
Network /
System / Enforce Minimum Minimum
Financial Password Password Password Password Account
# Application History Age Length Complexity | Lockout
Per Company Policy | 5 passwords 90 days 6 characters | Enabled 3 invalid
[working paper remembered login
(wip) ##] {1} attempts
Actual Testing Performed
Local Area 0 passwords 0 days 4 characters | Disabled 0 invalid
Network remembered {a} {a} {a} login
(LAN) / {a} attempts
Windows {a}
1 | Financial {b} {b} {b} {b} {b}
Application X
2 | Financial Option not 90 days 6 characters | Enabled 3 invalid
Application Y available— {c} {c} {c} login
Application attempts
limitation {c}
{dd}
Note: The password values above were obtained through observation, and with the
assistance
of [name of Information Security Administrator].
Tickmarks (explanations):
{1}—Password settings obtained from company policy. Copy of the company policy
supporting these settings is documented in w/p [##].
{a}—The Enforce Password History, Minimum Password Age, Minimum Password Length,
Password Complexity, and Account Lockout settings are not configured consistent
with company policy, and therefore, do not promote an acceptable level of security.
The value configured for Password Complexity has also been set to “Disabled.”
Password complexity requirements establish minimum password parameters not easily
compromised that users must follow in establishing their passwords, particularly at
the LAN/Windows level, which serves as the first layer of authentication.
Exceptions noted. Refer to w/p [##], where these exceptions have been listed.
{b}—Password security settings are controlled through the Windows operating system.
Therefore, the configuration of the LAN/Windows password settings covers this
application. Refer to the LAN/Windows row above.
{c}—Password security settings such as Minimum Password Age, Minimum Password
Length, Password Complexity, and Account Lockout have been configured consistent
with the company policy, promoting an adequate level of security. No exceptions
noted.
{d}—Application functionality limitations do not allow the enforcement of password
history.
Exceptions noted. Refer to w/p [##], where this exception has been listed.
Substantive audit tests are designed and conducted to verify the functional
accuracy, efficiency, and control of the audit subject. During the audit of a
financial application, for example, the IT auditor would build and process test
data to verify the processing steps of such an application.
Auditing-through-the-computer is a term that involves steps in addition to
those mentioned previously. Programs are executed on the computer to test and
authenticate application programs that are run in normal processing. Usually, the
financial audit team will select one of the many Generalized Audit Software
packages such as SAS, SPSS, Computer-Assisted Audit Techniques (CAATS), or CA-
Easytrieve(T) and determine what changes are necessary to run the software at the
installation. Financial auditors use this specific software wo do sampling, data
extraction, exception reporting, summarize and foot totals, and other tasks. They
also use packages such as Microsoft Access, Excel, IDEA, or ACL because of their
in-depth analyses and reporting capabilities.
CAATS, for example, use auditor-supplied specifications to generate a program
that performs audit functions, such as evaluating application controls, selecting
and analyzing computerized data for substantive audit tests, etc. In essence, CAATs
automate and simplify the audit process, and this is why audit teams (external and
internal) are increasingly using them. In fact, many organizations have Generalized
Audit Software already installed for their internal auditors to allow them to
gather information and conduct the planned audit tests. The appropriate selection
and effective use of these audit tools are essential not only to perform adequate
audit testing but also to document results.
Document Results
The next phase of an audit involves documenting results of the work performed, as
well as reporting on the findings. Audit results should include a description of
audit findings, conclusions, and recommendations.
Audit Findings
The terms finding, exception, deficiency, deviation, problem, and issue are
basically synonymous in the audit world, and mean the auditor identified a
situation where controls, procedures, or efficiencies can be improved. Findings
identify and describe inaccurate, inefficient, or inadequately controlled audit
subjects. An example of an IT audit finding would be a change implemented into a
financial application that did not include proper management authorization. Another
example would include the IT auditor discovering that the organization's procedures
manual does not require management's permission before implementing changes into
applications.
Audit findings should be individually documented and should at least include
the following:
Name of the IT environment (operating system hosting the relevant financial
application(s) evaluated
IT area affected (IS operations, information security, change control management)
Working paper test reference where the finding was identified
General control objective(s) and activity(ies) that failed
Brief description of the finding
Where is the finding formally communicated to management (this should reference
the Management Letter within the Auditor Report)
The individual classification of the finding per audit standard AU 325,
Communications About Control Deficiencies in an Audit of Financial Statements, as
either a deficiency, significant deficiency, or a material weakness”
Evaluation of the finding, specifically whether it was identified at the design
level (i.e.,there is no general control in place) or at the operational level
(i.e., the general control was in place,but did not test effectively)
Whether the finding represents or not a pervasive or entity-level risk
Whether the finding can be mitigated by other compensating general controls, and
if so, include reference to where these controls have been tested successfully
An audit finding form (e.g., General Computer Controls Findings Form, etc.) can be
used to review the control issues identified with the responsible IT manager in
order to agree on corrective action. This information can then be used to prepare
the formal Management Letter that will accompany the Audit Report and the
corrective action follow-ups. Taking corrective action could result in enhanced
productivity; the deterrence of fraud; or the prevention of monetary loss, personal
injury, or environmental damage. Exhibit 3.8 shows an example of a worksheet that
may be used to summarize the individual findings identified during an IT audit.
Conclusions and Recommendations

Conclusions are auditor opinions, based on documented evidence, that determine
whether an audit subject area meets the audit objective. All conclusions must be
based on factual data obtained and documented by the auditor as a result of audit
activity. The degree to which the conclusions are supported by the evidence is a
function of the amount of evidence secured by the auditor. Conclusions are
documented in the audit working papers and should support the audit procedures
performed. Working papers are the formal collection of pertinent writings,
documents, flowcharts, correspondence, results of observations, plans and results
of tests, the audit plan, minutes of meetings, computerized records, data files or
application results, and evaluations that document the auditor activity for the
entire audit period. A complete, well-organized, cross referenced, and legible set
of working papers is essential to support the findings, conclusions, and
recommendations as stated in the Audit Report. Typically, a copy of the final Audit
Report is filed in the working papers.
Recommendations are formal statements that describe a course of action that
should be implemented by the company’s management to restore or provide accuracy,
efficiency, or adequate control of audit subjects. A recommendation should be
provided by the auditor for each audit finding for the report to be useful to
management.
Communication
The value of an audit depends, in large part, on how efficiently and effectively
its results are communicated. At the conclusion of audit tests, it is best to
discuss the identified findings with IT management to gain their agreement and
begin any necessary corrective action. Findings, risks as a result of those
findings, and audit recommendations are usually documented on the Management Letter
(in a separate section of the Audit Report). Refer to Exhibit 3.9 for an example of
the format of a Management Letter from an IT audit.
* http://pcaobus.org/Standards/Auditing/Pages/AU325.aspx.
Exhibit 3.8 Example Supporting Documentation of the General Computer Control

Findings Identified
Company Name
GCC Findings
Fiscal Year 20XX
No/IT
Environment—IT
Area/W/P
Reference #
Where Finding
Was Identified
Control Objective
Failed Control
Activity
Brief Description of Finding

Communicated to
Management in
[W/P Reference # of IT
Management Letter]
Classification of Finding as a
Deficiency (Design or
Operating), Significant
Deficiency, or Material
Weakness
Finding Mitigated
By Other
Compensating
General Controls?
(If So, List Control.)
1/Windows—
Information
Security/W/P
Reference #
ISEC 2.00 -
Adequate
security is
implemented to
protect against
unauthorized
access and
modifications of
systems and
information,
which may result
in the processing
or recording of
incomplete,
inaccurate, or
invalid financial
information.
ISEC 2.04 - Users
who have
changed roles or
tasks within the
organization, or
that have been
transferred, or
terminated are
immediately
informed to the
security
department for
user account
access revision
in order to
reflect the new
and/or revised
status.
We noted that the notification

for termination from Human
Resources (HR) for two user
accounts selected for testing
was not received by IT
personnel within seven
business days. We also noted
that the user account of one
terminated employee
remained active in the
[financial application name].
Moreover, for five out of six
terminated employees
tested, notification of the
employee’s termination was
not sent immediately or
within seven business days
from the employee's
supervisor or HR to IT
personnel.
Operating Deficiency.
Deficiency does not
represent a material
weakness (i.e., will not
prevent, or detect and correct
material misstatements in the
financial statements). The
deficiency is also not severe
enough to merit the attention
of those charged with
governance (i.e, significant
deficiency). Simply, the
operation of the existing
control does not allow
management or employees,
in the normal course of
performing their assigned
functions, to prevent, detect,
and/or correct misstatements
on a timely basis.
[List the general

controls identified
(and successfully
tested) that can
mitigate or
compensate the
identified
finding.]
(Continued)
Exhibit 3.8 (Continued)
Example Supporting Documentation of the General Computer Control Findings

Identified
Company Name
GCC Findings
Fiscal Year 20XX
No/IT
Environment—IT
Area/W/P
Reference #
Where Finding
Was Identified
Control Objective
Failed Control
Activity

Communicated to
Management in
Management Letter]
Weakness
Finding Mitigated
By Other
Compensating
General Controls?
2/UNIX—
Information
Security/W/P
Reference #
ISEC 2.00 -
Adequate
security is
implemented to
protect against
unauthorized
access and
modifications of
systems and
information,
resulting in the
processing or
recording of
incomplete,
inaccurate, or
invalid
information.
ISEC 2.03 - User

account access
privileges are
periodically
reviewed by
systems and
application
owners to
determine
whether they are
reasonable and/
or remain
appropriate.
We noted no formal access

reviews were performed by
IT personnel and/or
business/application owners
for the relevant financial
applications in scope.
Same as above.
[List the general
controls identified
(and successfully
tested) that can
mitigate or
compensate the
finding.]
(Continued)
88 m Information Technology Control and Audit
Exhibit 3.8 (Continued) Example Supporting Documentation of the General Computer

Control Findings Identified
Company Name
GCC Findings
Fiscal Year 20XX
No/IT
Environment—IT
Area/W/P
Reference #
Where Finding
Was Identified
Control Objective
Failed Control
Activity

Communicated to
Management in
Management Letter]
Finding Mitigated
By Other
Compensating
General Controls?
3/Linux—
Information
Security/W/P
Reference #
ISEC 1.00 - Security
configuration of
applications,
databases,
networks, and
operating
systems is
adequately
managed to
protect against
unauthorized
changes to
programs and
data that may
resultin
incomplete,
inaccurate, or
invalid
processing or
recording of
financial
information.
ISEC 1.07 -
Passwords must
promote
acceptable levels
of security
(consistent with
policies and/or
best industry
practices) by
enforcing
confidentiality
and a strong
password
format.
Even though access to
[Financial Application 1, 2,
etc.] requires users to first
authenticate at the network
level, there were application-
level logical security settings
identified which were not in
accordance with the
company’s local password
policy, and may therefore
not promote optimal
security.
Same as above.
[List the general

controls identified
(and successfully
tested) that can
mitigate or
compensate the
finding.]

90 ® /nformation Technology Control and Audit
Exhibit 3.9 Example of a Management Letter from an IT Audit
Company Name
Management Letter—IT Audit
Year Ended December 31, 20XX
The findings below have been prioritized in order of significance and discussed
with [name
and title of company personnel responsible for IT], on [date when meeting took
place].
Findings marked with an asterisk (*) are repeated from prior years.
[Name of General Control IT Area (i.e., Information Systems Operations, Information

Security,
or Change Control Management)—Short Description of the Failed Control Activity]
FINDING
[Detailed description of the finding.
[EXAMPLE: During the fiscal year ended June 30, 20XX, the Company converted its
core
financial application from [Application #1] to [Application #2]. We noted that the
Company
had no established or documented formal policies and procedures regarding the
change
management process as it related to conversion of data from old to new systems,
applications, and databases.)
IT RISK
[Description of the IT risk related to the finding above.]
[EXAMPLE: Failure to implement appropriate general controls related to the

conversion of data
can result in operational disruptions, degraded system performance, or compromised
security.]
RECOMMENDATION
[Auditor recommendation is documented here.]
[EXAMPLE: The Company should formally document a change control policy to establish
procedures over each change's life cycle, including controls on data conversions.
Newly
developed policies should also be formally approved, communicated, and distributed
to end
users.]
MANAGEMENT RESPONSE
[The management's response should address responsibility and accountability for

implementation of a corrective action, as well as include a target implementation
date for
correction.]
[EXAMPLE: Management acknowledges and accepts the IT auditor recommendation. A plan

to
implement appropriate data conversion controls will be put in place and submitted
to our
CEO and CFO for their review and approval within the next month. General controls
related
to the conversion of data are expected to be designed and fully operational by the
next
year's IT audit.)
On receipt of the Management Letter, I'T management and affected staff should
review the document immediately. Those items not already completed should be
handled and followed-up. Within a relatively short time, the fact that all
discrepancies have been corrected should be transmitted to the audit staff in a
formal manner. These actions are noted in the audit files, and such cooperation
reflects favorably in future audits.
I. Risk assessment
Vulnerabilities
and threats
identification
Likelihood Risk
determination determination
System assets
characterization
| IL. Audit plan

. . —_— . . Audit team,
Comprehensive Risk Objectives and Audit Audit budget ’
understanding ™] assessment |] context ®| schedule |[°| and scoping tasks, and
eadlines
IV. Results and communication
III. Audit procedures
Test
Preliminary
review and
Aen Evaluate
audit controls?
Substantive
procedures i
testing
Exhibit 3.10 Summary of the audit process.
It is important to track corrective action to verify that findings have been

remediated. This requires a formal process to track corrective actions, target
dates, and status for reporting to I'T management, the audit committee, and the
board.
At the close of the audit, a draft Audit Report is issued for review by all
impacted parties. The review process will go much faster if findings have already
been agreed with management during the testing and conclusion phase. After the
Audit Report has been finalized, it is a good practice to schedule an exit meeting
involving both, IT and financial sides. Typically, invitations to the exit meeting
are sent to the CIO and the Chief Financial Officer (CFO) (or Controller if the CFO
is not available) to discuss the audit, as well as to review the audit objectives
and ask for feedback on the performance of the audit team. This meeting will
provide valuable information into the performance of the audit staff and lessons
learned for improving future engagements.
To summarize the audit process explained in this chapter, refer to Exhibit 3.10.
Other Types of IT Audits

Besides supporting financial statement audits, there are other highly-demanded
audit areas conducted in IT. These are briefly described next.
Enterprise Architecture
IT management must develop organizational procedures to ensure a controlled and
efficient architecture for information processing. These procedures should also
specify the computers and peripheral equipment required to support all functions in
an economic and timely manner. With enterprise systems being very critical to
medium-size and large businesses today, the need to monitor and validate
operational integrity of an enterprise resource planning system is an important
process. IT audit plays an important role in maintaining, validating, and
monitoring the entetprise architecture.
Computerized Systems and Applications

A computerized systems and applications type of audit verifies that the
organization’s systems and applications (operational and non-financial in nature)
are:
appropriate to the users’ needs,

efficient, and
adequately controlled to ensure valid, reliable, timely, and secure input,
processing, and
output at current and projected levels of system activity.
Information Processing Facilities

An audit of the information processing facility ensures timely, accurate, and
efficient processing of applications under normal and potentially disruptive
conditions.
Systems Development
An IT audit related to systems development would make certain that applications and
systems under development meet the objectives of the organization, satisfy uset
requirements, and provide efficient, accurate, and cost-effective applications and
systems. This type of audit ensures that applications and systems are written,
tested, and installed in accordance with generally accepted standards for systems
development.
Business Continuity Planning/Disaster Recovery Planning

According to the SysAdmin, Audit, Network, Security (SANS) Institute, a business
continuity (or resiliency) plan (BCP) incorporates activities and procedures to
recover all business operations (no just IT) from interruptions or adverse events.”
A disaster recovery plan (DRP) incorporates a set of procedures to recover and
protect the organization's IT infrastructure in the event of an emergency or
disaster. Both plans should be formally documented, and kept updated within the
organization.
A BCP audit evaluates how an organization's continuity processes are being
managed. This type of audit defines the risks or threats to the success of the
plan, and assesses the controls in place to determine whether those risks or
threats are acceptable and in line with the organization’s objectives." This audit
also quantifies the impact of weaknesses of the plan and offers recommendations for
business continuity plan improvements.
DRP audits help ensure that the IT infrastructure and all related equipment
used to develop,test, operate, monitor, manage, and/or support IT services (e.g.,
hardware, software, networks, data centers, etc.) are adequately maintained and
protected to ensure their continued availability consistent with organizational
objectives. A DRP audit considers factors such as alternate site designation,
training of personnel, and insurance issues, among others.
* www.sans.org/reading-room/whitepapers/recovery/introduction-business-continuity-
planning-559.
* http://searchdisasterrecovery.techtarget.com/definition/business-continuity-plan-
audit.
Conclusion
Over decades, the computer has been used to support daily operations in business
environments. Most companies find that they must use computer technology
effectively to remain competitive. The nature of technology, however, continues to
change rapidly. As a result, companies continue to integrate their
accounting/financial systems and operations. The audit profession has made these
adjustments as well. Worldwide, professional organizations have issued useful
guidance and instruction to assist managers and the audit professionals.
Whether the IT audit reviews information systems operations, information
security, or applications, the controls applied in those areas must be verified.
The IT auditor’s function (whether internal or external) provides reasonable
assurance that system assets are safeguarded, information is timely and reliable,
and errors and deficiencies are discovered and corrected promptly. Equally
important objectives of this function are effective controls, complete audit
trails, and compliance with organizational policies.
The nature of auditing will undoubtedly continue to undergo substantial change
as the level of technology improves. Full automation from project initiation to the
final reporting stage will enable auditors to make more efficient use of available
resources and enhance the credibility of the audit performed. Effective use of
computer technology can also empower auditors to better understand the design of
the client's computer system, as well as conduct successful audits in today’s
highly automated environments.
Review Questions
1.What is an audit universe and what does it include?

2.What is Control Objectives for Information and Related Technology (COBIT) and why
is it valuable to management and IT auditors?
3.Why are risk assessments significant to the audit function?
4.Summarize the importance of an audit plan. What are the four minimum steps an
audit plan should have?
5.State the significance of an audit schedule.
6.Describe what an audit scoping should include.
7.Briefly describe the eight typical phases of an audit engagement.
8.What specific information or evidence can an IT auditor gather for a client that
uses its IT environment to store and process financially significant data?
9.Explain what an audit program is.
10.Describe the procedures IT auditors perform in order to test controls,
processes, and exposures.
11.Describe the procedures typically performed when conducting an IT audit related
to
a.Systems Development
b.Business Continuity Planning/Disaster Recovery Planning
Exercises
1.As the IT audit senior of the engagement, you are presenting to the IT manager
and partner (as part of the planning meeting) the results of the risk assessment
performed in Exhibit 3.3. Based on such results (look at Exhibit 3.3, under the
“Risk Rating” and “Action Priority” columns), it seems clear that the audit should
focus on Financial Application #2 (FA2). Nevertheless, the IT manager and partner,
based on previous relevant experience, believe that the audit should be performed
on Financial Application #1 (FA1). The planning meeting is over, and you still feel
doubtful on the decision just made. Your task: Prepare a two-page memo to the audit
manager (copying the partner) stating your reasons why FA2 should be audited first.
In order to convince the audit manager and partner, you are to think “outside the
box.” In other words, think of additional information not necessarily documented in
the risk assessment shown in Exhibit 3.3, and document in your memo information
related to:
a.Any additional vulnerabilities or weaknesses that may currently be in place
affecting FA2
b.Any additional threat-sources that can trigger the vulnerabilities or weaknesses
you just identified for FA2
c.Any additional risks or situations involving exposure to loss for the financial
information in FA2
d.Any additional controls or procedures that should be implemented to mitigate the
risks just identified
2.Use the following information to prepare an IT Planning Memo similar to the one
in Appendix 1.
a.You are the I'T audit senior (or I'T auditor representative) assigned. Your audit
firm has several branches, but you are working this particular client from the
Melbourne, FL office.
b.The IT audit will support the financial statement audit of Company XYZ, with a
fiscal year ending on December 31, 20XX.
c.Discussions with the financial audit Director regarding IT audit involvement have
already taken place, and are documented in work paper (w/p) 1000.1. IT auditors
have not been involved in previous audits for this client.
d.Your team is composed of: IT Partner P, IT Manager M, and IT Audit Staff AS. You
are the IT audit Senior S.
e.The audit timing includes: Planning will be performed during the sixth month of
the year under audit; Interim audit procedures will take place during 2 months
before the end of the fiscal year; Year-end procedures are scheduled for January
through March of the year following the end of the fiscal year; and all work papers
and audit documentation will be due by and signed off on April 30th of the year
following the end of the fiscal year.
f.The IT audit is estimated to take 100 hours. Hours will be charged to client
code: Company XYZ-0000.
g.An understanding of Company XYZ’s IT environment is documented in w/p 1540.
h.The three relevant applications for the IT audit include are:
i.All Accounting Application (AAA)—used to capture and processing accounting-
related transactions. AAA is installed on a UNIX platform (or operating system),and
uses Oracle database. AAA can be accessed via a Windows network.
ii.Financial Document Generator Application (FDGA)—used to produce all types of
financial reports and documentation. FDGA is installed on a Windows operating
system, and uses Oracle as its database. FDGA is accessed via a Windows network.
iii.Human Resources and Payroll Application (HRPA)—used to manage the company’s
human resources and process payroll. This application is hosted outside of the
company, at a third-party organization called HRP-For-All.

i.The relevant application controls used to mitigate risks in this audit are listed
in Exhibit 3.5b (these must be added to the IT Planning Memo). Use w/p 1000.2 for
reference purposes.
j.Deviations or findings resulting from testing the relevant application controls
will be documented in w/p 2302.
k.There will be no work of others (e.g., Internal Audit personnel, etc.) used in
the IT audit.
l.Human resources and payroll services are performed by a third-party service
organization called HRP-For-All, located in Austin, Texas. Deloitte, the service
auditor, just finished issuing a report assessing the controls at the service
organization for the period July 1, 20XX through June 30, 20XX. Controls at HRP-
For-All were found to be effective.
m.There are no other areas identified within Company XYZ that IT auditors can
assist with.
3.How is substantive testing used in an IT audit? Explain what does the term
auditing- through-the-computer refers to.
4.What is an audit finding and which information should be included when
documenting them?
5.You are an external IT auditor asked to perform a review of the following: The
Financial Transactions Application (FTA) is causing a problem with the General
Ledger Application (GLA) due to the timing of the transfer of transactions. Data
were transferred late by FTA causing end-of-the-month reports to be inaccurately
stated. Managers met to review prior month’s activity reports, and noticed a
shortfall of $50,000 in some accounts. Prepare an audit plan to conduct procedures
to address this type of situation.
Further Reading
1.AICPA. Audit analytics and continuous audit—Looking toward the future,
www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/DownloadableDocuments/
AuditAnalytics_LookingTowardFuture.pdf (accessed August 2017).
2.Benson, J. (August 2007). The Importance of Monitoring. Internal Auditor.
Institute of Internal Auditors, Altamonte Springs, FL.
3.Berry, L. (October 2007). A Kinder, Gentler Audit. Internal Auditor. Institute of
Internal Auditors, Altamonte Springs, FL.
4.Bodin, L., Gordon, L., and Loeb, M. (2008). Information security and risk
management. Commun, ACM, 51(1), 64—68.
5.Casas, E. (October 2007). Tell It Like It Is. Internal Auditor. Institute of
Internal Auditors, Altamonte Springs, FL.
6.Cavusoglu, H., Mishra, B., and Raghunathan, S. (2004). A model for evaluating IT
security investments. Commun. ACM, 47(1), 87-92.
7.Chaney, C. and Gene, K. (August 2007). The Integrated Auditor. Internal Auditor.
Institute of Internal Auditors, Altamonte Springs, FL.
8.Deloitte LLP. (2014). IT Audit Planning Work Papers. Unpublished internal
document.
9.EY’s ten key IT considerations for internal audic—Effective IT risk assessment
and audit planning. (February 2013). Insights on governance, risk and compliance,
www.ey.com/Publication/vwLUAssets/Ten_key IT
_considerations_for_internal_audit/$FILE/Ten_key_IT_considerations_for_internal_aud
it.pdf
10.Flipek, R. (June 2007). IT Audit Skills Found Lacking. Internal Auditor.
Institute of Internal Auditors,Altamonte Springs, FL.
11.Gallegos, F. (2002). The audit report and follow up: Methods and techniques for
communicating audit findings and recommendations. Inf Syst. Control J., 4, 17-20.
12.Gallegos, F. and Preiser-Houy, L. (2001). Reviewing Focus Database Applications,
EDP Auditing Series, 74-10-23, Auerbach Publishers, Boca Raton, FL, pp. 1-24.
13.Hyde, G. (August 2007). Enhanced Audit Testing. Internal Auditor. Institute of
Internal Auditors,Altamonte Springs, FL.
14.Information Systems Audit and Control Foundation. COBIT, 5th Edition,
Information Systems Audit and Control Foundation, Rolling Meadows, IL,
www.isaca.org/Knowledge-Center/COBIT/Pages/Overview.aspx (accessed June 2012).
15.IS Audit Basics. The Process of Auditing Information Systems,
www.isaca.org/knowledge-center/itaf-is-assurance-audit-/pages/is-audit-basics.aspx
(accessed July 2017).
16.Manson, D. and Gallegos, F. (September 2002). Auditing DBMS Recovery Procedures,
EDP Auditing Series, 75-20-45, Auerbach Publishers, Boca Raton, FL, pp. 1-20.
17.McAfee Labs 2017 threats predictions, report issued on November 2016,
www.mcafee.com/au/resources/reports/rp-threats-predictions-2017.pdf (accessed
October 2017).
18.McAfee Labs threats report—December 2016,
www.mcafee.com/ca/resources/reports/rp-quarterly-threats-dec-2016.pdf (accessed
October 2017).
19.McCafferty, J. (2016). Five Steps to Planning an Effective IT Audit Program, MIS
Training Institute, http://misti.com/internal-audit-insights/five-steps-to-
planning-an-effective-it-audit-program
20.Menkus, B. and Gallegos, F. (2002). Introduction to IT Auditing, #71-10-10.1,
Auerbach Publishers,Boca Raton, FL, pp. 1-20.
21.National Vulnerability Database. National Institute of Standards and Technology,
https://nvd.nist.gov/vuln/search (accessed August 2017).
22.Otero, A. R. (2015). An information security control assessment methodology for
organizations’financial information. Ins. J. Acc. Inform. Syst., 18(1), 26-45.
23.Otero, A. R. (2015). Impact of IT auditors’ involvement in financial audits. nz.
J. Res. Bus. Technol.,6(3), 841-849.
24.Otero, A. R., Tejay, G., Otero, L. D., and Ruiz, A. (2012). A fuzzy logic-based
information security control assessment for organizations, IEEE Conference on Open
Systems, Kuala Lumpur, Malaysia.
25.Otero, A. R., Otero, C. E., and Qureshi, A. (2010). A multi-criteria evaluation
of information security controls using Boolean features. Int. J. Network Secur.
Appl., 2(4), 1-11.
26.Pareek, M. (2006). Optimizing controls to test as part of a risk-based audit
strategy. Inf Sysz. Audit Control Assoc. J., 2, 39-42.
27.Romney, M. B. and Steinbart, P. J. (2015). Accounting Information Systems, 13th
Edition, Pearson Education, Upper Saddle River, NJ.
28.Richardson, V. J., Chang, C. J., and Smith, R. (2014). Accounting Information
Systems, McGraw Hill,New York.
29.SANS’ Information Security Policy Templates,
www.sans.org/security-resources/policies/general(accessed October 2016).
30.Sarbanes-Oxley-101. Section 404: Management Assessment of Internal Controls,
www.sarbanes-oxley-101.com/SOX-404.htm (accessed August 2016).
31.Senft, S., Gallegos, F., and Davis, A. (2012). Information Technology Control
and Audit, CRC Press/Taylor & Francis, Boca Raton, FL.
32.Singleton, T. (2003). The ramifications of the Sarbanes—Oxley Act. Inf Syst.
Control J, 3, 11-16.
33.U.S. General Accounting Office, Assessing the Reliability of Computer Processed
Data Reliability, https://digital.library.unt.edu/ark:/67531/metadc302511/
(accessed November 2016).
34.U.S. General Accounting Office, Government Auditing Standards 2017 Exposure
Draft, www.gao.gov/yellowbook (accessed May 2017).
35.U.S. General Accounting Office, Standards for Internal Control in the Federal
Government, September 2014, GAO/AIMD 00-21.3.1.

Chapter 3 Otero

Uploaded by

Copyright:

Available Formats

Chapter 3 Otero

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 3 Otero

Uploaded by

Copyright:

Available Formats

Chapter 3

The IT Audit Process

The role of IT audit continues to be a critical mechanism for ensuring the

60 ®m [nformation Technology Control and Audit

The audit universe is also an essential building block to a properly risk-

a. Establishing principles, policies, and practical guidance for daily management.

Exhibit 3.1 Example of an Audit Universe Related to the IT Area of an Organization

Basic Functional Audit Area: Information Technology

Change Control Management Programs and systems are appropriately implemented in

62 Bm [nformation Technology Control and Audit

Exhibit 3.2 Principles of the COBIT 5 framework. (Adapted from

c. Putting in place organizational structures with key decision-making

COBIT 5 assists organizations in adequately separating governance from management

a. Governance—optimizes the use of organizational resources to effectively address

identifying new risk areas

64 m [nformation Technology Control and Audit

Absolute security from threads and risks in today’s technology environments is

Likelihood Determination Impact

Financial IS Operations/ | Hurricanes, Medium 0.50 High 75 [FA1 information 37.5 |

for data unexpected the event of to minimize risk

backups to shutdowns system failure, that data are lost.

the event of a information

Information Unauthorized | High 0.75 High 75 [Security 56.25 | The identity of

FA1 are not user access Passwords must

The IT Audit Process BB 65

66 ® Information Technology Control and Audit

Likelihood Determination Impact

Unauthorized | Low 0.25 High 75

FA2 changes are

Changes to FA2 are

The IT Audit Process B® 67

68 ®m [nformation Technology Control and Audit

1. List the audit objectives and describe the context

The IT Audit Process BB 69

Objectives and Context

IT Audits Conducted to Support Financial Statement Audits

70 ® [nformation Technology Control and Audit

Audit Budget and Scoping

Audit Team, Tasks, and Deadlines

Exhibit 3.4 Example of a Budget for an IT Audit

Fiscal Year 20XX

First year. Gather and document an 3.0 1.0 0.0 4.0

Subsequent years. Review and update

Conduct planning meeting with 1.0 1.0 1.0 3.0

Subtotal 7.0 3.0 1.0 11.0 11%

Information Systems Operations 16.0 0.0 0.0 16.0

Information Security 17.0 0.0 0.0 17.0

Change Control Management 20.0 0.0 0.0 20.0

Subtotal 53.0 0.0 0.0 53.0 53%

Exhibit 3.4 (Continued) Example of a Budget for an IT Audit

Fiscal Year 20XX

Exhibit 3.5a Example of Scoping for Financial Applications

Financial Applications and their Association with Business Processes

Fiscal Year 20XX

Purpose: To identify relevant applications by mapping them to their corresponding

Financial Payroll & | Inventory

UNIX Oracle Local Data X X X X

AS/400 Oracle Local Data X

The IT Audit Process ® 73

Exhibit 3.5a (Continued) Example of Scoping for Financial Applications