Вы находитесь на странице: 1из 40

Chapter 17 Page 98

CHAPTER 17
IT CONTROLS PART III: SYSTEMS DEVELOPMENT,
PROGRAM CHANGES, AND APPLICATION
CONTROLS
REVIEW QUESTIONS:
1.

Systems development controls:

a. systems authorization activities


b. user specification activities
c.

technical design activities

d. internal audit participation


e. program testing
f.

user test and acceptance procedures


Systems maintenance controls:

a. technical specifications, authorization, testing, and documentation


b. source program library controls

Chapter 17 Page 99

2.

All program modules must be thoroughly tested before they are implemented. The
test data must be designed such that all modules are tested. Oftentimes,
hypothetical master files and transactions are created so that every possible
situation can be tested. The results of the test are compared against predetermined
results to identify programming and logic errors.
3.

Users need to be actively involved in the systems development process.


The technical complexity of the system should not stifle user involvement.
Regardless of the technology involved, the user should create a detailed
written description of his or her needs. The creation of a user specification
document often involves the joint efforts of the user and systems
professionals. However, this document must remain a statement of user
needs. It should describe the users view of the problem, not that of
systems professionals alone.

4.

The internal auditor can serve as a liaison between users and the systems
professionals to ensure an effective transfer of knowledge. An internal audit
group, astute in computer technology and possessing a solid grasp of the
business problems to be solved, is invaluable to the organization during all
phases of the SDLC. Internal auditors should therefore become formally
involved at the inception of the systems development process to oversee
the definition of user needs requirements and appropriate controls.
Furthermore, this involvement should continue throughout all phases of
development and maintenance activities.

5.

The purpose of program testing in the SDLC is to test and verify all aspects

Chapter 17 Page 100

of the program modules' logic.

Chapter 17 Page 101

6.

The simplest form of check digit is to sum the digits in the code and use this sum as
the check digit. This allows the integrity of the code to be established during
subsequent processing and for transcription errors and transposition errors to be
detected.

7.

All program modules must be thoroughly tested before they are implemented. A
program testing procedure involving the creation of hypothetical master files and
transactions files. The results of the tests are then compared against predetermined
results to identify programming and logic errors.

8.

Source program library (SPL) is a disk repository for storing application program
modules in source code format. To make a program change requires first changing
the logic of the source code on the SPL. This is then recompiled and linked to create
a new load module that incorporates the changed code. Clearly, protecting the
source code on the SPL is central to protecting the production application.

9.

The black box surrounding the SPL signifies the SPLMS, which controls four critical
functions: (1) storing programs on the SPL, (2) retrieving programs for maintenance
purposes, (3) deleting obsolete programs from the library, and (4) documenting
program changes to provide an audit trail of the changes.

10.

When using program-naming conventions, the name assigned to a program clearly


distinguishes it as being either a test or a production program. When a program is
copied from the production SPL to the programmers library, it is given a temporary
test name. When the program is returned to the SPL, it is renamed with its original
production name. This technique greatly reduces the risk of accidentally running an
untested version of a program in place of the production program.

Chapter 17 Page 102

11. The SPLMS assigns a version number automatically to each program stored on the
SPL. When programs are first placed in the libraries (at implementation), they are
assigned version number zero. With each modification to the program, the version
number is increased by one.
12. a.

reconcile program version numbers

b. confirm maintenance authorization


13. a.

reconcile the source code

b. review test results


c.

retest the program

14. Auditing around the computer involves black box testing in which the auditors do not
rely on a detailed knowledge of the applications internal logic. Input is reconciled
with corresponding output. Auditing through the computer involves obtaining an indepth understanding of the internal logic of the computer application. As transactions
become increasingly automated, the inputs and outputs may become decreasingly
visible. Thus, the importance of understanding the programming components of the
system is crucial.
15. a.

authenticity tests

b. accuracy tests
c.

completeness tests

d. redundancy tests
e. access tests
f.

audit trail tests

g. rounding error tests

Chapter 17 Page 103

16. EAM techniques use one or more specially programmed modules embedded in a
host application to select and record predetermined types of transactions for
subsequent analysis. This method allows material transactions to be captured
throughout the audit period. The auditors substantive testing task is thus made
easier since they do not have to identify significant transactions for substantive
testing.
17. GAS allows auditors to access electronically coded data files of their clients, both
simple and complex structures, and to perform various operations on their contents.
GAS is popular for the following reasons:
a. the languages are easy to use and require little EDP background on the part of
the user
b. it may be used on any form of computer because it is hardware-independent
c.

auditors can perform their tests on data independent of a computer services


professional

d. it can be used to audit the data files of many different applications

Chapter 17 Page 104

18.
Access tests, validity tests, accuracy tests, completeness tests, redundancy tests and
audit trail tests.
19. Many times data have upper and lower limits to their acceptable values. For
example, if the range of pay rates for hourly employees in a firm is between 8 and 20
dollars, this control can examine the pay rate field of all payroll records to ensure
that they fall within this range.
20. The test determines that a value in one field, which has already passed a limit check
and a range check, is reasonable when considered along with data in other fields of
the record.

DISCUSSION QUESTIONS

Chapter 17 Page 105

1.

An SPL environment can help to deter unauthorized changes to programs by


implementing password-controlled libraries for each programmer where the
passwords are frequently changed. Program modification reports are a powerful
control for detecting and deterring any unauthorized program changes. These
reports describe in detail all program changes that have been made. These reports
should be reconciled against program maintenance requests to verify that only the
changes requested were made. Another control SPLMS provides is the automatic
assignment of a new program version number each time a program is changed.
Maintenance commands can be used to mitigate all of the above controls since the
commands can be used to alter/eliminate passwords, alter the program version
number, and temporarily modify a program without generating a record of the
modification. Management, or some security group, should tightly control the
authority to use maintenance commands.

Chapter 17 Page 106

2.

One example would be students grades. This information is considered confidential


and private. The student, his/her advisor, and his/her professors should have access
to this data. Other students should NOT have access to any students grade other
than their own. Prospective employers or other universities should not have access
to the grades without the permission of the student. Health information kept at the
university health center should be considered private. Only the student and the
health professionals should have access to these individual records unless consent
is given by the student. University officials may receive summary health data
regarding all students, but not individual students. Also, student transcripts that
contain information regarding disciplinary probation should only be accessed by the
student unless permission is granted by the student to release this transcript.

3.

Prior to system implementation, User Test and Acceptance Procedures provide


formal and rigorous testing of the the individual modules of the system. The test
team should be composed of user personnel, systems professionals, and internal
auditors. The details of the tests performed and their results need to be formally
documented and analyzed. Once the test team is satisfied that the system meets its
stated requirements, the system can be transferred to the user. Many consider the
formal testing and acceptance event to be the most important control over the
systems development process. This is the last point at which the user can determine
the systems acceptability prior to it going into service. Whereas discovering a major
flaw at this juncture is costly, discovering it later, during day-to-day operations, may
be devastating.

Chapter 17 Page 107

4.

Prior to system implementation, User Test and Acceptance Procedures provide


formal and rigorous testing of the the individual modules of the system. The test
team should be composed of user personnel, systems professionals, and internal
auditors. The details of the tests performed and their results need to be formally
documented and analyzed. Once the test team is satisfied that the system meets its
stated requirements, the system can be transferred to the user. Many consider the
formal testing and acceptance event to be the most important control over the
systems development process. This is the last point at which the user can determine
the systems acceptability prior to it going into service. Whereas discovering a major
flaw at this juncture is costly, discovering it later, during day-to-day operations, may
be devastating.

5.

The salami fraud affects large numbers of victims, but each in a minimal way. The
fraud scheme takes its name from the analogy of slicing a large salami (the total
fraud) into many thin pieces. Each victim gets one of these small pieces and is
unaware of being defrauded. For example, a programmer, or someone with access
to the rounding program can modify the rounding logic to perpetrate a salami fraud
as follows: at the point in the process where the algorithm should increase the
current customers account (that is, the accumulator value is > +.01), the program
instead adds one cent to the perpetrators account. Although the absolute amount of
each fraud transaction is small, given the hundreds of thousands of accounts
processed, the total amount of the fraud becomes significant over time.

Chapter 17 Page 108

6.

The black box approach (also called auditing around the computer) does not require
the auditor to create test files or to obtain a detailed knowledge of the applications
internal logic. Instead, auditors analyze flowcharts and interview knowledgeable
personnel in the clients organization to understand the functional characteristics of
the application. With an understanding of what the application is supposed to do, the
auditor tests the application by reconciling actual production transactions processed
with output results. The output results are analyzed to verify the applications
compliance with its functional requirements. Black box testing is feasible for
applications that are relatively simple, with inputs and outputs that are easily
reconciled. More complex applications, however, often draw input data from multiple
sources, perform a variety of complex operations, and produce multiple outputs.
These applications demand more intensive through-the-computer testing to provide
the auditor with evidence of application integrity. Through-the-computer testing
employs computer-assisted audit tools and techniques (CAATTs) and requires an indepth understanding of the internal logic of the application under review.

Chapter 17 Page 109

7.

Test data should consist of a complete set of valid and invalid transactions.
Incomplete test data may fail to explore critical branches of application logic and
error checking routines. Test transactions should be designed to test all possible
input errors, logical processes, and irregularities pertinent to the audit objective.
Gaining knowledge of the applications internal logic sufficient to create meaningful
test data represents a considerable investment in time. The efficiency of this task is
improved, however, through careful planning during systems development. Systems
designers should save for future use the test data created to test program modules
during the implementation phase of the SDLC. If the application has undergone no
changes since its initial implementation, then the current audit test results should
equal the original test results obtained at implementation. If the application has been
changed, the auditor need only create additional test data that focus on the areas of
the program changes.

8.

The primary disadvantage of test data techniques is that auditors rely on the clients
IT personnel to obtain a copy of the production application under review. The risk
here is that the IT personnel may intentionally or accidentally provide the auditor with
the wrong version of the application. Audit evidence collected independently is more
reliable than evidence the client supplies.

9.

Auditors need to ensure that systems being developed in-house serve the needs of
all users and that the risk of material errors in the systems being developed and
those in use is acceptable.

10. a.

Detecting

that

inadequate

programmers and operators

segregation

of

functions

exists

between

Chapter 17 Page 110

b. Finding

different

program

versions

running

documentation
c.

Finding undocumented program maintenance

than

expected

based

on

Chapter 17 Page 111

11. Embedded audit module (EAM) techniques use one or more specially programmed
modules embedded in a host application to select and record predetermined types of
transactions for subsequent analysis. As the selected transaction is being processed
by the host application, a copy of the transaction is stored in an audit file for
subsequent review. The EAM approach allows material transactions to be captured
throughout the audit period. Captured transactions are made available to the auditor
at period end or at any time during the period, significantly reducing the amount of
work the auditor must do to identify significant transactions for substantive testing.
12. The test data method is used to establish application integrity by processing
specially prepared sets of input data through production applications that are under
review. The results of the test are compared with the expected results. The base
case system evaluation extends the test data method; the test data set constrains all
possible transaction types. Tracing is an electronic walk-through of the applications
internal logic and analysis of the execution of each program command line for a
specific transaction. An integrated test facility is an automated technique that
enables the auditor to test an applications logic and controls during its normal
operations by creating dummy transactions and files. This method promotes ongoing
application auditing. Parallel simulation involves creating a simulation of the
transaction processing system and then using actual transactions to determine if the
results of the auditors processing reconcile with the organizations results.

Chapter 17 Page 112

13.

When auditors rely on client IT personnel to produce flat files from their databases,
they run the risk that database integrity will be compromised. For example, if the
auditor is confirming accounts receivable, certain fraudulent accounts in the original
database may be intentionally omitted from the flat file provided to the auditor.
Auditors skilled in relational and object database technology can avoid this problem.
Not surprisingly, public accounting firms are aggressively seeking employees with
strong computer skills to accompany their accounting training.

MULTIPLE CHOICE
1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

PROBLEMS

Chapter 17 Page 113

1. The auditor will create the following test data and perform the following tests to
evaluate the accuracy of inventory receipts in the receiving department.
a.

Test data should consist of a complete set of valid and invalid inventory
receiving transactions. Test transactions should be designed to test all possible
input errors, logical processes, and irregularities pertinent to the audit objective.
Results from testing will be in the form of routine output reports, transaction
listings, and error reports that are normally produced by the application. In
addition, the auditor must examine the updated master files to determine that
inventory records have been correctly updated. The test results are then
compared with the auditors expected results. The auditor will examine error
report of rejected transactions, and a listing of the updated AR master file. Any
deviations between the actual results and those the auditor has predetermined
may indicate a logic error or control problem.

b. TESTING ACCURACY OF POSTINGS TO INVENTORY ACCOUNTS. The


auditor would create a master file of inventory records (AR). The transactions
would consist of a wide range of transactions to see if the control is functioning
properly. This test data is used to see if approved transactions (are accurately
posted to the inventory accounts in the test master files. The auditor verifies
their accuracy by reviewing account balance reports produced by the inventory
receiving application and reconcile them with the predetermined results.
Discrepancies would indicate a logic error in the math calculation or an error
that posts transactions to the wrong accounts.

Chapter 17 Page 114

c. TESTING THE THREE-WAY MATCH. This test involves creating two test
master files: a purchase order file and a receiving report file. The transaction in
this case is the suppliers invoice. The test data should be designed to contain
discrepancies that fall both within and outside of acceptable limits, based on
company policy. When the invoice is entered, the AP system should match the
three documents (create a digital AP packet) and reconcile the quantities
ordered with those received, and the invoice amount with the expected price.
The auditor will reconcile both rejected and accepted invoices to determine that
the control is functioning in accordance with company policy.
d. TESTING MULTILEVEL SECURITY AND ACCESS PRIVILEGES IN THE
PURCHASES/AP SYSTEM. This test involves creating several master files:
purchase order file; inventory file; receiving report file; and general ledger
accounts for cash, inventory control, and AP control. The auditor then logs into
the system under different roles and attempt to perform tasks and access data
that are not authorized by the various roles. Failure to detect or prevent such
attempts indicates a control weakness in the system.

2.
Identification and Description of
Type of Fraud

Explanation

Protection Methods

Chapter 17 Page 115

a. Input

Input manipulation requires the least

Documentation and Authorization

Manipulation

amount of technical skill and almost


no knowledge of how the computer

Data input formats properly documented and


authorized

system operates. Input documents

Programmed terminal/user protection

are improperly altered or revised

Programs designed to accept only certain

without authorization, e.g., payroll

inputs from designated users, locations,

time cards/time sheets can be altered

terminals, and/or times of the day.

to pay overtime or an extra salary.


b. Program

Program alteration requires

Programmers should only make changes to

Alteration

programming skills and knowledge of

copies of production source programs and data

the program. The program coding is

files, never to the actual production files.

revised for fraudulent purposes, e.g.,

Segregation of Duties

ignore certain transactions such as


overdrafts against the programmers

Computer operators should not have direct


access to production programs or data files.

account, draw checks and have them Periodic Comparisons


sent to a falsely constructed account,

Internal Audit or some other independent group

grant excessive discounts to certain

should have copies of the official programs, or

specified trade accounts, etc.

access to the master programs, so as to periodically


process actual data and compare the output with
output obtained from normal operations. Any output
changes would be indicative of unauthorized
program changes.

Periodic comparisons of online programs to


offline backup copies to detect changes.

c. File

File alteration occurs when the

Restricted Access to Equipment/Files

Alteration

defrauder revises specific data or

Restrict access to the computer center.

manipulates data files, e.g.,

Programmers, analysts, and computer

fraudulently changing the rate of pay

operators should not have direct access to

of an employee in the payroll master

production data files.

file via a program instruction; or

transferring balances among dormant

Production data files are maintained in a


library under the control of a librarian or

Chapter 17 Page 116

database administrator.

accounts to conceal improper

withdrawals of funds.

Computer operators should not have access to


applications documentation, except where needed
to perform their duties, to minimize their ability to
modify programs and data files.

d. Data Theft

Data theft can be accomplished by data

Electronic sensitization of all library materials for

interception over a network, by access to

detection if unauthorized removal from the library

files and central databases, and by

is attempted.

physical removal of data files and of hard

Sensitive transmitted and stored data should be

copies of reports. With considerable

encrypted using secured encryption methods

amounts of information being transmitted

such as RSA.

over the Internet and private networks,


data are vulnerable to interception. Data
stored in corporate databases are subject
to theft from privileged employees and
external hackers. Individuals with
physical access to secure areas may

Access to data files should be password


protected and authority tables should be created
for personnel that accurately reflect their access
needs and legitimate authority levels.
Audit trail software can be installed to monitor
access attempts via networks and offsite locations.

remove reports and hard copy printouts


of files.
e. Sabotage

The physical destruction of hardware

Terminated employees immediately denied

or software.

access to all computer equipment and


information to prevent their ability to destroy or
alter equipment or files.
Maintain backup files at secure off-site locations.

3.
Audit Plan
Operating System Controls
AUDIT OBJECTIVES RELATING ACCESS PRIVILEDGES

Chapter 17 Page 117

The objective of the auditor is to verify that access privileges are granted in a
manner that is consistent with the need to separate incompatible functions and is in
accordance with organizational policy.
AUDIT PROCEDURES

Review the organizations policies for separating incompatible functions and


ensure that they promote reasonable security.

Review the privileges of a selection of user groups and individuals to determine


if their access rights are appropriate for their job descriptions and positions.

Review personnel records to determine whether privileged employees undergo


an adequately intensive security clearance check in compliance with company
policy.

Review employee records to determine whether users have formally


acknowledged their responsibility to maintain the confidentiality of company
data.

Review the users permitted logon times. Permission should be commensurate


with the tasks being performed.

AUDIT OBJECTIVES RELATING TO PASSWORDS


The auditors objective here is to ensure that the organization has an adequate and
effective password policy for controlling access to the operating system.
AUDIT PROCEDURES

Verify that all users are required to have passwords.

Verify that new users are instructed in the use of passwords and the importance

Chapter 17 Page 118

of password control.

Determine that procedures are in place to identify weak passwords.

Assess the adequacy of password standards such as length and expiration


interval.

Review the account lockout policy and procedures. The auditor should
determine how many failed-logon attempts are allowed before the account is
locked.

AUDIT OBJECTIVE RELATING TO VIRUSES AND OTHER DESTRUCTIVE


PROGRAMS
The auditors objective is to verify that effective management policies and
procedures are in place to prevent the introduction and spread of viruses and other
destructive programs.
AUDIT PROCEDURES

Through interviews with operations personnel, determine that they have been
educated about computer viruses and are aware of the risky computing
practices that can introduce and spread viruses and other malicious programs.

Review operations procedures to determine if floppy disks are routinely used to


transfer data between workgroups.

Verify that system administrators routinely scan workstations and file servers for
viruses.

Verify that new software is tested on standalone workstations prior to being


implemented on the host or network server.

Chapter 17 Page 119

Verify that the current version of antiviral software is installed on the server and
that upgrades are regularly downloaded to workstations.

AUDIT OBJECTIVES RELATED TO AUTOMATED AUDIT TRAILS


The auditors objective is to ensure that the auditing of users and events is adequate
for preventing and detecting abuses, reconstructing key events that preceded
systems failures, and planning resource allocation.
AUDIT PROCEDURES

The auditor can use general-purpose data extraction tools such as ACL for
accessing archived log files to search for defined conditions such as:

Unauthorized or terminated user.

Periods of inactivity.

Activity by user, workgroup, or department.

Logon and logoff times.

Failed logon attempts.

Access to specific files or applications.

The auditor should select a sample of security violation cases and evaluate their
disposition to assess the effectiveness of the security group.

AUDIT OBJECTIVES RELATED TO FAULT TOLERENCE


The auditors objective is to ensure that the organization is employing an appropriate
level of fault tolerance.
AUDIT PROCEDURES

The auditor should determine if the level of RAID in place is adequate for the

Chapter 17 Page 120

organization, given the level of business risk associated with disk failure.

If the organization is not employing RAID, the potential for a single point of
system failure exists. The auditor should review with the system administrator
alternative procedures for recovering from a disk failure.

Determine that copies of boot disks have been made for each server on the
network in the event of a boot sector failure. Ensure that the disks are secured
and access to them restricted to the system administrator.

System Maintenance Controls


AUDIT OBJECTIVES RELATED TO SYSTEMS MAINTENANCE.
The auditors objective is to detect unauthorized program maintenance (which may
have resulted in significant processing errors or fraud) and to determine that 1.
maintenance procedures protect applications from unauthorized changes, 2.
applications are free from material errors, and 3. program libraries are protected
from unauthorized access.
AUDIT

PROCEDURES

FOR

IDENTIFYING

UNAUTHORIZED

PROGRAM

CHANGES.
To establish that program changes were authorized, the auditor should examine the
audit trail of program changes and confirm that authorization procedures were
followed by performing the following tests of controls.
Reconcile Program Version Numbers. The permanent file of the application should
contain program change authorization documents that correspond to the current
version number of the production application. Any discrepancies between version

Chapter 17 Page 121

numbers and supporting documents may indicate that unauthorized changes were
made.
Confirm Maintenance Authorization. The program maintenance authorization should
indicate the nature of the change requested and the date of the change. The auditor
should confirm the facts contained in the maintenance authorization and verify the
authorizing signatures with the managers involved.
AUDIT PROCEDURES FOR IDENTIFYING APPLICATION ERRORS
Reconcile the Source Code. Each applications permanent file should contain the
current program listing and listings of all changes made to the application. These
documents describe in detail the applications maintenance history.
Review Test Results. Every program change should be thoroughly tested before
being implemented. The auditor should review the record for each significant
program change to establish that testing was sufficiently rigorous to identify any
errors.
Retest the Program. The auditor can retest the application to confirm its integrity.
AUDIT PROCEDURES FOR TESTING ACCESS TO LIBRARIES
The auditor should establish that the program library and private libraries are protected
from unauthorized access by performing the following tests of controls.
Review Programmer Authority Tables. The auditor can select a sample of
programmers and review their access authority. The programmers authority table
will specify the libraries a programmer may access. These authorizations should be

Chapter 17 Page 122

matched against the programmers maintenance authority to ensure that no


irregularities exist.
Test Authority Table. The auditor should simulate the programmers access privileges and
then violate the authorization rules by attempting to access unauthorized libraries. Any such
attempts should be denied by the operating system.
Organizational Structure Controls
AUDIT OBJECTIVES RELATED TO ORGANIZATIONAL STRUCTURE
The auditors objective is to verify that individuals in incompatible areas are
segregated in accordance with the level of potential risk and in a manner that
promotes a working environment.
AUDIT PROCEDURES
The following tests of controls would enable the auditor to achieve the control
objectives.

Obtain and review the corporate policy on computer security. Verify that the security
policy is communicated to responsible employees and supervisors.

Review relevant documentation, including the current organizational chart,


mission statement, and job descriptions for key functions, to determine if
individuals or groups are performing incompatible functions.

Review systems documentation and maintenance records for a sample of


applications. Verify that maintenance programmers assigned to specific projects
are not also the original design programmers.

Through observation, determine that segregation policy is being followed in

Chapter 17 Page 123

practice. Review operations room access logs to determine whether


programmers enter the facility for reasons other than system failures.

Review user rights and privileges to verify that programmers have access
privileges consistent with their job descriptions.

4.

One area to examine is whether Golden Gate has purchased and received a
material amount of inventory and/or machinery in the last month and not yet
received or paid the invoice. One plan would be to trace all (or a sample) of
receiving reports during the last month and make sure that they are either included
in an accounts payable journal entry (if invoice has been received) or in an adjusting
entry for accruals (if invoice has not yet been received). Another area to examine is
whether interest on notes, bonds, etc. have been accrued. An examination of all debt
instruments will be necessary to determine if the appropriate interest has been
accrued.

5.

Potential exposureunauthorized changes to the application programs have been


made, and that the EAMs have been turned off while the unauthorized application
programs were being run.
The external auditors should make sure that:
1. strict control procedures are in place regarding program changes; all such
changes should be authorized and documented. The program version numbers
should reconcile to the number of changes made.
2. the programmers should only have access to source code, not the running copy
or the compilers.
3. if CASE tools are being used, the auditors should verify that controls are built-in

Chapter 17 Page 124

regarding the documentation of program changes.


6.

Potential exposure:
1. The internal auditors should NOT report to the controller. This could cause a
conflict of interest. The internal auditors should report to the CEO or the Board
of Directors.
2. The controller and the internal auditors may be covering up fraudulent activities
by having the new test data set rigged so that certain branches of the
application logic are not tested.
The external auditors should:
1. Create a new test data set and examine the results.
2. Maintain a copy of the new test data set at home office.
3. Process the data test set created by the internal auditor with the accounting
firms library copy of the application program and compare with the results of the
current application program.
4. Recommend that the internal auditors report to the Board of Directors in the
future or disregard any work provided by them.
5. Examine the program version numbers and change requests to assess whether
any program changes have been made.

Chapter 17 Page 125

7.

The concern is that many immaterial invoices may add up to a material amount. If
an organized, carefully planned scheme to embezzle numerous small payments by
customers is in effect, then the confirmation process will not catch the scheme since
small invoice amounts will not be subjected to the confirmation process. An
elaborate lapping of accounts receivable can escape detection if no further detection
techniques are employed. The auditors should first investigate the current years
accounts receivable balance. A sample of immaterial invoices should be investigated
and subjected to the confirmation process. Only if discrepancies are found should
the prior years accounts receivable be considered for investigation.

8.

The auditor must sometimes rely on computer services personnel to produce a flat
file from the complex file structures. There is a risk that data integrity will be
compromised by the procedure used to create the flat file. In this case, where the
auditors objective is to confirm accounts receivable, certain fraudulent accounts in
the complex structure may be intentionally omitted from the flat-file copy that is
created. The sample of confirmations drawn from the flat file may therefore be
unreliable. Auditors skilled in programming languages may avoid this potential pitfall
by writing their own data extraction routines.

9.

Internal control issues:


Organizational Structure
Programmers and operators who perform incompatible functions may perpetrate
program fraud.

The functions of programming, computer operations, tape librarian, and


database administration should be organizationally segregated.

Chapter 17 Page 126

Systems Development
The development of unauthorized projects can result in the misappropriation of
financial resources. Inefficient allocation of resources during development, lead to
poorly developed systems.
Systems authorizations, user specification activities, technical design activities,
internal audit participation, program testing, and acceptance procedures need
adequate time and resources for proper completion.
Systems Maintenance
Unauthorized changes can result in program errors, fraud, incorrect information
presented in financial statements and to users, systems failures, and severe
disruptions to operations.

Program

maintenance

authorization,

user

involvement,

technical

specifications, program testing, documentation and program source code library


access control need to be identified and maintained appropriately.
Internal Audit Participation
Though often overlooked, the internal audit should be involved as an outside view
and a form of independent verification. Specialized audit groups that understand and
have experience with systems in programming languages can be deployed through
all process of development and maintenance.
Testing procedures
This is considered to be the most important part of SDLC. Testing should ensure:

Transaction Authorization: All transactions by the system are valid and legal.

Chapter 17 Page 127

Access Control: Once the system is operational, who will have access to it.
This also constitutes allowing logins and password protection at differentiated
levels.

Segregation of duties: Do the programmers have access to the system later?


Do the operators have access to the source code (refer to the figure on the next
page)?

The main issues that all systems should account for are:
1. Unauthorized access for financial gain or other illicit purposes
2. Intentional or unintentional insertion of viruses into the operating system
3. Loss of data due to system malfunction that goes unnoticed
Separating new systems development from Maintenance
1. The systems analysis group works with the user to produce a detailed design of the
new system. The programming group codes the programs according to these design
specifications. These two duties should be separated and segregation of duties is
very important at this stage. (Also refer to answer for question 2, for further details
about segregation of duties and its importance).
2. Under the current system, the programmer who codes the original program
(Siman II) also maintains the program later. This can lead to the following
problems:
Program Fraud
Since the programmer also has full access to the program source code, he can
implement hidden subroutines and access points that will allow him to use the
program for personal benefits. In this case, since the company deals with managing

Chapter 17 Page 128

wealth and money market accounts, the programmer can easily have funds diverted
to his personal account. Lack of such segregation of duties can lead to further
weaknesses in internal controls such as:

Access Control: The programmer now has access to all files and sensitive

data of the company and the clients. Given his expertise he can manipulate that
information without knowledge of management.

Transaction Authorization: He might perform transactions that are not valid

such as investing for personal gains. Since, the programmer will have access to
the maintenance of the program after the development stage; he can access
these hidden routines and run them unnoticed to management.

Chapter 17 Page 129

Documentation Inadequacy
As mentioned in the case, the programmers were under heavy pressure to code the
new version of Siman as competitors were ahead. The two major problems that
occurred here were that they skipped the quintessential step of proper documentation
while coding. And secondly, since they are also going to be working as maintenance for
the system later, the documentation will be sparse and only meant to refresh their
memory about specific routines and procedures. Thus, the documentation would almost
be like a set of personal notes for the programmers. This defeats the purpose of
documentation. The documentation is intended to allow future programmers to read and
understand the system so they can work on it as efficiently as the original programmer.
This leads to a second problem of dependency where the programmers are now
indispensable to the company as they are the only ones who understand the system.
This places significant responsibility in the hands of management presenting the
following internal control issues:

Audit Trail: The documentation is intended to be part of the audit trail to suffice in
terms of validation of costs and resource implementation. It also enables

Chapter 17 Page 130

auditors to track personnel utilization and need for systems that could be
expensive.

Independent Verification: The documentation provides a key resource for


independently verifying the protocols and procedures of the system. Improper
documentation could lead to this step being avoided, which gives more
autonomy to the programmers.

10. a. Advantages of using audit software to assist with audits include the following:

Audits can be more efficient, saving labor and time spent on routine
calculations.

The

routine

operations

of

footing

extensions,

transcription between reports, and report generation are computer


generated as a result of the software.

The auditor's time spent on the audit is more analytical than


clerical.

The auditor is able to examine more records and extract desired


data more readily through ad hoc reporting.

Computer-generated reports and schedules are more objective and


professional, improving data communication.

Audit sampling is improved. Any bias in sample selection is


eliminated because of assured randomness. This has a direct effect
on sampling precision, reliability, and audit accuracy.

Examples of use include:


1. Footing and balancing entire files or selected data items.

Chapter 17 Page 131

2. Selecting and reporting detailed data contained on files.


3. Selecting stratified statistical samples from data files.
4. Formatting results of tests into reports.
5. Printing confirmations in either standardized or special wording.
6. Screening data and selectively including or excluding items.
7. Comparing two files and identifying any differences.
8. Recalculating data fields.

b.
1. Integrated Test Facility

The integrated test facility (ITF) approach is an automated technique that


enables the auditor to test an applications logic and controls during its normal
operation. The ITF involves one or more audit modules designed into the
application during the systems development process. In addition, ITF
databases contain dummy master file records integrated among legitimate
records.

The steps involved in performing ITF testing are:

ITF transactions must be created to test all logic branches in the application.

During normal operations, the test transactions are merged into the input
stream of regular (production) transactions and are processed against the
dummy accounts.

After processing, the auditor compares the processing results with

Chapter 17 Page 132

predetermined results to verify that processes and controls function as


expected.

2. Embedded Audit Module


Embedded audit module (EAM) techniques use one or more programmed modules
embedded in a host application to select, for subsequent analysis, transactions that
meet predetermined conditions. As the selected transaction is being processed by
the host application, a copy of it is stored on an audit file for subsequent review. The
EAM approach allows material transactions to be captured throughout the audit
period. Captured transactions are retrieved by the auditor at period end or at any
time during the period, thus significantly reducing the amount of work the auditor
must do to identify significant transactions for substantive testing. Though primarily a
substantive testing technique, EAMs may also be used to monitor application
controls on an ongoing basis as recommended in the COSO framework.
The steps involved in performing parallel simulation testing are:

The auditor specifies to the EAM system the parameters and materiality
threshold of the transactions set to be captured. Transactions equal to or
greater than set threshold will be copied to the audit file. Transactions that fall
below this threshold will be ignored by the EAM.

From the set of selected transactions, the auditor will choose a subset to be
used for substantive tests.

Chapter 17 Page 133

For example, transactions selected by the EAM can be reviewed for proper
authorization, completeness and accuracy of processing, and correct posting
to accounts.

3. Parallel Simulation
Parallel simulation involves creating a program that simulates key features or
processes of the application under review. The simulated application is then used to
reprocess transactions that were previously processed by the production application.
The results obtained from the simulation are reconciled with the results of the
original production run to determine if application processes and controls are
functioning correctly.
The steps involved in performing parallel simulation testing are:

The auditor must first gain a thorough understanding of the application


under review. Complete and current documentation of the application is
required to construct an accurate simulation.

The auditor must then identify those processes and controls in the
application that are critical to the audit. These are the processes to be
simulated.

The auditor creates the simulation using a fourth-generation language or


generalized audit software.

The auditor runs the simulation program using selected production


transactions and master files to produce a set of results.

Finally, the auditor evaluates and reconciles the test results with the
production results produced in a previous run.

Chapter 17 Page 134

11. a.
Systems Authorization Activities
All systems should be properly authorized to ensure their economic
justification and feasibility. This requires a formal environment in which users
submit requests to systems professionals in written form.
User Specification Activities
Users need to be actively involved in the systems development process.
User involvement should not be stifled by the technical complexity of the
system. Regardless of the technology involved, the users should create
detailed written descriptions of their needs. The creation of a user
specification document often involves the joint efforts of the user and
systems professionals. However, this document must remain a statement
of user needs. It should describe the users view of the problem, not that
of the systems professionals.
Technical Design Activities
The technical design activities translate user specifications into a set of
detailed technical specifications for a system that meets the users needs.
The scope of these activities includes systems analysis, feasibility analysis,
and detailed systems design. The adequacy of these activities is reflected in
the quality of the documentation that emerges from each phase.
Internal Audit Participation
To meet the governance-related expectations of management under SOX, an
organizations internal audit department needs to be independent, objective,
and technically qualified. As such, the internal auditor can play an important
role in the control of systems development activities. An internal audit group,

Chapter 17 Page 135

astute in computer technology and possessing a solid grasp of the business


problems to be solved, is invaluable to the organization during all phases of
the SDLC.
Program Testing
All program modules must be thoroughly tested before they are implemented.
The results of the tests are then compared against predetermined results to
identify programming and logic errors. The auditor should verify that all
braches of the application's logic has been tested.

The task of creating

meaningful test data is time consuming. The data should therefore be saved
and will give the auditor a frame of reference for designing and evaluating
future audit tests. For example, if a program has undergone no maintenance
changes since its implementation, the test results from the audit should be
identical to the original test results. Having a basis for comparison, the auditor
can thus quickly verify the integrity of the program code.
User Test and Acceptance Procedures
Prior to system implementation, the individual modules of the system need to
be formally and rigorously tested as a whole. The test team should comprise
of user personnel, systems professionals, and internal auditors. The details of
the tests performed and their results need to be formally documented and
analyzed. Once the test team is satisfied that the system meets its stated
requirements, the system can be transferred to the user.
b.
In meeting the audit objectives the auditor would select a sample of system
projects completed during the period and verify that they were properly
authorized , that users were involved in specifying their needs, and that the
internal auditor was actively involved in all decision phases of the project.
The auditor would also verify that each phase of the SDLC was followed and

Chapter 17 Page 136

evidenced with the appropriate documentation. The auditor should verify that
applications were tested and that the test data and results were preserved as
evidence. The auditor would determine that the overall system underwent
formal test and acceptance procedures.
The auditors would also examine the audit trail of program changes by
reconciling

program

version

numbers

and

confirming

maintenance

authorizations. The auditors identify application errors by reconciling the


source code, reviewing test results, and re-testing the program.
12.

a. Five different areas in this payroll application with inadequate controls.


i. The payroll processing system violates the principle of segregation of
duties in several areas as the same individual verifies the time cards,
inputs payroll information into the master file, prints the checks,
machine-signs the checks, distributes the checks, and prepares the
payroll journal entry.
ii. There is no authorization of employees time cards by a supervisor or
other objective party such as a time keeper.
iii. The payroll checks are not prenumbered nor are they properly stored. As
a result, there is no audit trail to verify check usage.
iv. There is no control over the machine-signing of checks such as control
of the signature plate by a second party or the use of a log to record
activity.
v. The data processing department appears to have full access to the
payroll files and checks, which could lead to sensitive payroll information
being leaked.
b. Two areas in the payroll system in which system controls are satisfactory:

Chapter 17 Page 137

i. The personnel department determines the wage rate and initiates the
setup of payroll records, which is a good example of segregation of
duties.
ii. A backup of the master file is made after each weekly processing of the
payroll.

Оценить