Sie sind auf Seite 1von 41

Chapter 17

IT Controls Part III:


Systems Development,
Program Changes, and
Application Controls

Principles of Accounting Information


Systems, Asia Edition
James A. Hall

©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Objectives for Chapter 17
 Be familiar with the controls and audit tests
relevant to the systems development process.
 Understand the risks and controls associated
with program change procedures and the role
of the source program library.
 Understand the auditing techniques (CAATTs)
used to verify the effective functioning of
application controls.
 Understand the auditing techniques used to
perform substantive tests in an IT
environment.
2
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Systems Development Activities

 Authorizing development of new systems


 Addressing and documenting user needs
 Technical design phases
 Participation of internal auditors
 Testing program modules before implementing
 Testing individual modules by a team of users,
internal audit staff, and systems professionals

3
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
System Development Life Cycle

Figure 14-1

4
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Systems Development
Auditing objectives: ensure that...
 SDLC activities are applied consistently
and in accordance with management’s
policies
 the system as originally implemented was
free from material errors and fraud
 the system was judged to be necessary
and justified at various checkpoints
throughout the SDLC
 system documentation is sufficiently
accurate and complete to facilitate audit
and maintenance activities
5
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Systems Development IC
 New systems must be authorized.
 Feasibility studies were conducted.
 User needs were analyzed and addressed.
 Cost-benefit analysis was done.
 Proper documentation was completed.
 All program modules must be thoroughly
tested before they are implemented.
 Checklist of problems was kept.

6
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
System Maintenance IC
 Last, longest and most costly phase of
SDLC
 Up to 80-90% of entire cost of a
system
 All maintenance actions should require
 Technical specifications
 Testing
 Documentation updates
 Formal authorizations for any changes
7
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Program Change
Auditing objectives: detect
unauthorized program
maintenance and determine that...
 maintenance procedures protect
applications from unauthorized
changes
 applications are free from material
errors
 program libraries are protected from
unauthorized access 8
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Source Program Library

 Source program library (SPL)


 library of applications and software
 place where programs are
developed and modified
 once compiled into machine
language, no longer vulnerable

9
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Uncontrolled Access to the SPL

Figure 17-2

10
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Controlled SPL Environments
 SPL Management Systems (SPLMS)
protect the SPL by controlling the
following functions:
 storing programs on the SPL
 retrieving programs for maintenance
purposes
 deleting obsolete programs from the
library
 documenting program changes to
provide an audit trail of the changes
11
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Source Program Library under the
Control of SPL Management Software

Figure 17-3

12
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
SPL Control Features
 Password control
 Separation of test libraries
 Audit trails
 Reports that enhance management
control and the audit function
 Assigns program version numbers
automatically
 Controlled access to maintenance
commands
13
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
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
14
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
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
15
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
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

16
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
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
17
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
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

18
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
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

19
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Application Processing Controls

 Programmed processes that


transform input data into
information for output
 Three categories:
 Batch controls
 Run-to-run controls
 Audit trail controls
20
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Application Processing Controls
 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
21
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
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
22
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Transaction Log to Preserve
the Audit Trail

Figure 17-7

23
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
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.

24
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Stages in the Output Process

Figure 17-8
25
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
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
26
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
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

27
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
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

28
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
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
29
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Auditing Around the Computer -
The Black Box Approach

Figure 17-9

30
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Auditing through the Computer:
The ITF Technique

Figure 17-14
31
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Testing Application Controls

 Black Box Approach – focuses on


input procedures and output results
 To Gain need understanding…
 analyze flowcharts
 review documentation
 conduct interviews

32
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
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
33
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
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

34
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
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
35
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
The Parallel Simulation Technique

Figure 17-15

36
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Substantive Testing
 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
37
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
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

38
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Embedded Audit Module
Technique

Figure 17-16
39
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
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

40
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Using GAS to Access
Complex File Structure

Figure 17-18

41
©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.

Das könnte Ihnen auch gefallen