IT Audit Control
17 April 2019
Control Concepts
Control technologies are changing in two different ways. On
the one hand as mentioned before, basic manual and
automated controls are now part of the design of modern
hardware and software systems.
Control Objectives
Major control objectives are considered to be as
follows:
Safeguarding of assets
Guarantee data accuracy, reliability and authorization
Operation efficiency
Compliance with organizational policies and procedures
Lack of Control
Lack of control can generally mean the following
risks:
Erroneous decisions
Fraud
Business interruption
Excessive costs
Competitive disadvantages
Illegal situations
Control Environment
Controls can be grouped according to the
following three environments:
Accounting Controls - Procedures, etc.
Processing Controls - Data completeness and reliability
Environmental Controls - (All others)
Control Scope
The Control Scope defines to which resource it applies to in a
given moment of the Audit, such as the facilities, the systems or
specific data. In particular, the following resources:
Data: External and internal data objects, structured and non-
structured data, graphics, sound, etc.
Application Systems: That is, the sum of manual and
programmed procedures.
Technology: Hardware, operating systems, database
management systems, networking, multimedia, etc.
Facilities: Resources to house and support, Information
Systems.
People: Including staff skills, awareness and productivity to
plan, organize, acquire, deliver, support and monitor
Information Systems and Services.
Program Change
Auditing procedures: verify that programs were
properly maintained, including changes
Specifically, verify…
identification and correction of unauthorized program
changes
identification and correction of application errors
control of access to systems libraries
7
Application Controls
Narrowly focused exposures within a specific
system, for example:
accounts payable
cash disbursements
fixed asset accounting
payroll
sales order processing
cash receipts
general ledger
8
Application Controls
Risks within specific applications
Can affect manual procedures (e.g., entering data) or
embedded (automated) procedures
Convenient to look at in terms of:
input stage
processing stage
output stage
INPUT PROCESSING OUTPUT
9
Application Input Controls
Goal of input controls - valid, accurate, and
complete input data
Two common causes of input errors:
transcription errors – wrong character or value
transposition errors – ‘right’ character or value, but
in wrong place
10
Application Input Controls
Check digits – data code is added to produce a control
digit
especially useful for transcription and
transposition errors
Missing data checks – control for blanks or incorrect
justifications
Numeric-alphabetic checks – verify that characters are in
correct form
11
Application Input Controls
Limit checks – identify values beyond pre-set limits
Range checks – identify values outside upper and lower
bounds
Reasonableness checks – compare one field to another to
see if relationship is appropriate
Validity checks – compares values to known or standard
values
12
Application Processing Controls
Programmed processes that transform input
data into information for output
Three categories:
Batch controls
Run-to-run controls
Audit trail controls
13
Application Processing Controls
A batch job is a computer program or set of programs
processed in batch mode. This means that a sequence
of commands to be executed by the operating system is
listed in a file (often called a batch file, command file, or
shell script) and submitted for execution as a single unit.
Batch controls - reconcile system output with the input
originally entered into the system
Based on different types of batch totals:
total number of records
total dollar value
hash totals – sum of non-financial numbers
14
Application Processing Controls
Run-to-run controls - use batch figures to
monitor the batch as it moves from one
programmed procedure (run) to another
Audit trail controls - numerous logs used so that
every transaction can be traced through each
stage of processing from its economic source to
its presentation in financial statements
15
Transaction Log to Preserve the Audit
Trail
Figure 17-7
16
Application Output Controls
Goal of output controls is to ensure that system
output is not lost, misdirected, or corrupted, and
that privacy is not violated.
In the following flowchart, there are exposures at
every stage.
17
Stages in the Output Process
Figure 17-8
18
Application Controls Output
Output spooling – creates a file during the printing
process that may be inappropriately accessed
Printing – create two risks:
production of unauthorized copies of output
employee browsing of sensitive data
19
Application Controls Output
Waste – can be stolen if not properly disposed of,
e.g., shredding
Report distribution – for sensitive reports, the
following are available:
use of secure mailboxes
require the user to sign for reports in person
deliver the reports to the user
20
Application Controls Output
End user controls – end users need to inspect sensitive
reports for accuracy
shred after used
Controlling digital output – digital output message can
be intercepted, disrupted, destroyed, or corrupted as it
passes along communications links
21
Testing Application Controls
Techniques for auditing applications fall into two
classes:
1. testing application controls – two general approaches:
– black box – around the computer
– white box – through the computer
2. examining transaction details and account
balances—substantive testing
22
Auditing Around the Computer -
The Black Box Approach
Figure 17-9
23
Auditing through the Computer:
The ITF Technique
Figure 17-14
24
Testing Application Controls
Black Box Approach – focuses on input procedures
and output results
To Gain need understanding…
analyze flowcharts
review documentation
conduct interviews
25
Testing Application Controls
White Box Approach - focuses on understanding
the internal logic of processes between input and
output
Common tests
Authenticity tests
Accuracy tests
Completeness tests
Redundancy tests
Access tests
Audit trail tests
Rounding error tests 26
White Box Testing Techniques
Test data method: testing for logic or control problems -
good for new systems or systems which have undergone
recent maintenance
base case system evaluation (BCSE) - using a comprehensive
set of test transactions
tracing - performs an electronic walkthrough of the
application’s internal logic
Test data methods are not fool-proof
a snapshot - one point in time examination
high-cost of developing adequate test data
27
White Box Testing Techniques
Integrated test facility (ITF): an automated, on-going
technique that enables the auditor to test an application’s
logic and controls during its normal operation
Parallel simulation: auditor writes simulation programs and
runs actual transactions of the client through the system
28
The Parallel Simulation Technique
Figure 17-15
29
Substantive Testing
Substantive testing is an audit procedure that examines
the financial statements and supporting documentation to see if
they contain errors. These tests are needed as evidence to support
the assertion that the financial records of an entity are complete,
valid, and accurate.
Techniques to substantiate account balances. For example:
search for unrecorded liabilities
confirm accounts receivable to ensure they are not overstated
Requires first extracting data from the system. Two technologies
commonly used to select, access, and organize data are:
embedded audit module
generalized audit software
30
Embedded Audit Module
An ongoing module which filters out non-material
transactions
The chosen, material transactions are used for sampling in
substantive tests
Requires additional computing resources by the client
Hard to maintain in systems with high maintenance
31
Embedded Audit Module Technique
Figure 17-16
32
Generalized Audit Software
Very popular & widely used
Can access data files & perform operations on
them:
screen data
statistical sampling methods
foot & balance
format reports
compare files and fields
recalculate data fields
33
Change Management
Change management is the discipline that guides how
we :
Prepare
Equip
Support individuals to successfully adopt change
In order to drive organizational success and outcomes.
How?
By assuring that all proposed changes are evaluated
By prioritizing changes
By requiring that all changes are thoroughly tested
A back-out plan
By ensuring that the configuration management
system is updated to reflect the effect of any
changes.
Facts
No matter where you are in the system life cycle, the
system will change.
The desire to change it will persist throughout the life
cycle.
The services should be stable, reliable, and
predictable.
The services should be able to change rapidly to meet
evolving business requirements.
Source of Change
Objective of Change Management
To maximize speed-to-competence at minimized cost –
this is the basic conundrum faced by executives.
To effectively control risk – in people as well as process.
To recognize resistance to formal change management
and to use activities within change management
specifically targeted to overcome that resistance. This is a
recursive approach which is almost unique across the
portfolio of everyday management processes.
Software Change Management
Procedures
Change Management Roles
Change Management Process
Creating a Request for Change
Incidents that necessitate the change
Description of how the change would be implemented
The impact that the change would have on all associated
systems
A risk assessment
Contact information for everyone involved in the change
An outline of who will need to approve the request
A backup plan to follow in case the change is not successful
Impact Analysis
It provides accurate understanding of the implications of a
proposed change.
Which helps the team make informed business decisions
about which proposals to approve.
Three aspects:
1- Understand the possible implications of making the change.
2- Identify all the files, models, and documents.
3- Identify the tasks and estimation of efforts.
Impact Analysis
Checklist of possible implications of a proposed change.
Checklist of possible software elements affected by a
proposed change.
Impact Analysis cont..
Estimating effort for a requirement change
Impact Analysis cont..
Identify the sequence in which the tasks must be performed.
Determine whether the change is on the project’s critical
path
Estimate the impact on project’s schedule and cost.
Evaluate the change’s priority by estimating the relative
benefit, penalty, cost, and technical risk compared to other
discretionary requirements.
Report the impact analysis results
In most cases, this procedure shouldn’t take more than a
couple of hours
Reviewing
Evaluate the request based on its priority , impact analysis
If requests relate to problems that have already been
addressed.
Determine who would be responsible for fulfilling the
request.
Implementers’ ability to dedicate time to making the
change.
Planning
Resources that are needed to complete the change.
A timeline for implementation.
Testing
Test will demonstrate the procedure to be followed in
case the change request is approved.
Testing the change gives you the opportunity to work out
any problems in the procedures that you have developed.
Creating a Change Proposal
Outlines the type of change.
The priority associated with a change request
The outcomes that could occur if the change is not made
Implementing Changes
Implementing a change is not a simple process.
Once the change has been made, tests must be done.
If the change is not successful , backup plan
Reviewing Change Performance
Understand whether your change procedures are
working as expected.
Determine the accuracy of estimates that were made
before a request was fulfilled.
Reviewing change performance gives you the
opportunity to fine-tune your change management
process for better results in the future
Closing the Process
You must be sure that the entire process has been
documented in a database that all stakeholders can
access .
