CONTROLLING AND

AUDITING THE
SYSTEMS
DEVELOPMENT LIFE
CYCLE
 In a CBIS environment,
financial data are processed
(accessed, stored and
Controlling updated) by computer
and
applications.
Auditing
the SDLC The accuracy and integrity of
these programs directly
affects the accuracy of the
client’s financial data.

2
 ◦ A properly
functioning
systems ◦ The systems
development maintenance
process ensures
process
that only needed
ensures that
Systems applications are
only legitimate
created, that
Developme they are properly changes are
nt and specified, that made to
they possess applications
Maintenanc adequate and that such
e Process controls, and that
changes are
they are
also tested
thoroughly
tested before
before being
being implemented.
implemented.

3
 “
Controlling
New Systems
Development

4
 Five Controllable Activities

1. Systems Authorization Activities

Controlling
New 2. User Specification Activities
Systems
Developme 3. Technical Design Activities
nt
4. Internal Audit Participation

5. User Test and Acceptance

Procedures

5
 1. Systems Authorization Activities

All systems must be properly authorized to

ensure their economic justification and
feasibility. Typically, this requires that each new
system request be submitted in writing by users
Controlling to systems professionals who have both the
New Systems expertise and authority to evaluate and approve
(or reject) the request.
Development
2. User Specification Activities

Users must be actively involved in the systems

development process. Their involvement should
not be stifled because the proposed system is
technically complex.

6
 3. Technical Design Activities

The technical design activities translate the

user specifications into a set of detailed
technical specifications of a system that
Controlling meets the user’s needs. The scope of these
New activities includes systems analysis, general
systems design, feasibility analysis, and
Systems detailed systems design.
Developme
4. Internal Audit Participation
nt
The auditor should become involved at the
inception of the process to make conceptual
suggestions regarding system requirements
and controls. Auditor involvement should
continue throughout all phases of the
development process and into the
maintenance phase.
7
 5. User Test and Acceptance Procedures

Just before implementation, the individual

modules of the system must be tested as a
Controlling unified whole. A test team comprising user
personnel, systems professionals, and internal
New audit personnel subjects the system to
Systems rigorous testing. Once the test team is
satisfied that the system meets its stated
Developme requirements, the system is formally accepted
nt by the user department(s). The user’s
acceptance of the new system should be
formally documented.

8
Audit Objectives Related to New Systems
Development

• Verify that SDLC activities are applied consistently and in

accordance with management’s policies.

• Determine that the system as originally implemented was free from

material errors and fraud.

• Confirm that the system was judged to be necessary and justified at

various checkpoints throughout the SDLC.

• Verify that system documentation is sufficiently accurate and

complete to facilitate audit and maintenance activities.

9
Audit Procedures Related to New Systems Development
The auditor should select a sample of completed projects and review
the documentation for evidence of compliance with SDLC policies. Specific
points for review should include determining the following:

• User and computer services management properly authorized the project.

• A preliminary feasibility study showed that the project had merit.
• A detailed analysis of user needs was conducted that resulted in alternative
general designs.
• A cost–benefit analysis was conducted using reasonably accurate figures.
• The project’s documentation shows that the detailed design was an appropriate
and
accurate solution to the user’s problem.
• Test results show that the system was thoroughly tested at both the individual
module
and the total system level before implementation
• There is a checklist of specific problems detected during the conversion period,
along with evidence that they were corrected in the maintenance phase.
• Systems documentation complies with organizational requirements and
standards.

10
 “
Controlling
Systems
Maintenanc
e
11
Upon implementation, the system enters the maintenance
phase of the SDLC. This is the longest period in the SDLC,
often spanning several years. It is important to recognize
that systems do not remain static throughout this period.
Rather, they may undergo substantial changes that
constitute a financial outlay many times their original cost.

Two Controllable Activities

1. Maintenance Authorization, Testing, and Documentation

2. Source Program Library Controls

12
Maintenance Authorization, Testing, and
Documentation
Access to systems for maintenance purposes increases the possibility of
systems errors. Logic may be corrupted either by the accidental
introduction of errors or intentional acts to defraud. To minimize the
potential exposure, all maintenance actions should require, as a minimum,
four controls: formal authorization, technical specification of the changes,
retesting the system, and updating the documentation.

Source Program Library Controls

In larger computer systems, application program source code is stored on

magnetic disks called the source program library (SPL). To execute a
production application, it must first be compiled and linked to create a
load module that the computer can process. As a practical matter, load
modules are secure and free from the threat of unauthorized modification.

13
The Worst-Case Situation: No Controls

This arrangement has the potential to create the

following two serious forms of exposure:

1. Access to programs is completely unrestricted.

Programmers and others can access any programs
stored in the library, and there is no provision for
detecting an unauthorized intrusion.

2. Because of these control weaknesses, programs are

subject to unauthorized changes. Hence, there is no
basis for relying on the effectiveness of other controls
(maintenance authorization, program testing, and
documentation).
14
 A
Controlled
SPL
Environme
nt
 To control the SPL, protective features and
procedures must be explicitly addressed, and
this requires the implementation of an SPL
management system (SPLMS). This software
is used to control four routine but critical
functions:

1. Storing programs on the SPL,

Controlled
SPL 2. Retrieving programs for maintenance
Environme purposes,
nt
3. Deleting obsolete programs from the

library, and

4. Documenting program changes to provide

an audit trail of the changes.

16
The mere presence of an SPLMS does not guarantee program
integrity. SPL requires specific planning and control techniques to
ensure program integrity.

Control Techniques

1. Password Control

2. Separate Test Libraries

3. Audit Trail and Management Reports

4. Program Version Numbers

5. Controlling Access to Maintenance Commands

17
 ◦ Detect unauthorized program
maintenance (which may have
resulted in significant
Audit processing errors or fraud).
Objectives ◦ Determine that (1)
Related to maintenance procedures
System protect applications from
Maintenanc unauthorized changes, (2)
e applications are free from
material errors, and (3)
program libraries are protected
from unauthorized access.

18
 IDENTIFY UNAUTHORIZED
CHANGES
Tests of Controls
◦ Reconcile program version numbers
Audit ◦ Confirm maintenance authorization
Procedures IDENTIFY APPLICATION
Related to ERRORS
System Tests of Controls
Maintenanc ◦ Reconcile the source code
e ◦ Review test results
◦ Retest the program
TEST ACCESS TO LIBRARIES
Tests of Controls
◦ Review programmer authority tables
◦ Test authority table
19