Controlling and Auditing the

SDLC
 Systems Development and Program
Change Activities
• Participants in Systems • The Systems Development Life Cycle
• Systems Planning—Phase I
Development
• Systems Analysis—Phase II
• Why Are Accountants and • Conceptual Systems Design—Phase III
Auditors Involved with SDLC? • System Evaluation and Selection—Phase IV
• How Are Accountants Involved • Detailed Design—Phase V
with the SDLC? • Application Programming and Testing—
Phase VI
• Information Systems Acquisition • System Implementation—Phase VII
• In-House Development • Systems Maintenance—Phase VIII
• Commercial Systems • Controlling and Auditing the SDLC
• Controlling New Systems Development
• The Controlling Systems Maintenance
 CONTROLLING AND AUDITING THE
SDLC
• In a CBIS environment, financial data are processed (accessed, stored, and updated) by
computer applications.
• The accuracy and integrity of these programs directly affects the accuracy of the client’s financial data.
• The accuracy of the financial data in the client’s databases bears directly on the auditor’s opinion.

• The purpose of a financial audit is to provide an expert opinion regarding the fair
presentation of the FSs.

• To render such an opinion, the expert auditor must perform two (2) types of audit tests:
• 1) Tests of the accuracy and completeness of an application’s processes
• 2) Tests of computer application controls
 CONTROLLING AND AUDITING THE SDLC
• 1) Tests of the accuracy and completeness of an application’s processes
• Effect on substantive testing: If the computer applications process data
correctly and accurately, reduce the amount of substantive testing.

• Two (2) testing techniques that provide information about the accuracy
and completeness of an application’s processes (Chap. 7):
• (1) the black box (around the computer) approach
• an understanding of the functional characteristics of the application by analyzing
flowcharts and interviewing knowledgeable personnel in the client’s organization.
• (2) the white box (through the computer) approach.
• an in-depth understanding of the internal logic of the application being tested.
 CONTROLLING AND AUDITING THE SDLC
• 2) Tests of Computer Application Control
• If SDLC controls are effective, then limit the extent of application
testing:
• If SDLC controls are weak and inconsistently applied, application
testing and substantive testing cannot be reduced. In some
situations, it may even be necessary to expand the scope of the
audit.
 CONTROLLING AND AUDITING THE
SDLC
• A properly functioning systems development process ensures that
• 1) only needed applications are created.
• 2) they are properly specified
• 3) they possess adequate controls
• 4) they are thoroughly tested before being implemented.

• Risk: A materially flawed financial application can corrupt financial

data, which are then incorrectly reported in the FSs.
 Controlling New System Development
• Five (5) controllable activities for the original system:
• 1) Systems Authorization Activities
• 2) User Specification Activities
• 3) Technical Design Activities
• 4) Internal Audit Participation
• 5) User Test and Acceptance Procedures
 Controlling New System Development
5 Controllable Features
Activities
1) Systems •All systems must be properly authorized to ensure their economic
Authorization Activities justification and feasibility.
•Users should submit System request to systems professionals to evaluate
and approve (or reject) the request.
2) User Specification •Users must provide a detailed written description of the logical needs that
Activities must be satisfied by the system in the form of User specification document.
3) Technical Design •The quality of the documentation that emerges from each phase is both a
Activities control and evidence of control and is critical to the system’s long-term
success.
 Controlling New System Development
5 Controllable Features
Activities
4) Internal Audit •Make suggestions regarding system requirements and controls.
Participation •Serve as a liaison between users and the systems professionals to ensure
an effective transfer of knowledge.
•Should become involved and can make a valuable contribution to all
aspects of the SDLC process.
5) User Test and •Test team (user personnel, systems professionals, and internal audit
Acceptance Procedures personnel) subjects the system to rigorous testing.
•Formal testing and acceptance of the system by the user is considered by
many auditors to be the most important control over the SDLC.
 Controlling Systems Maintenance
• The systems maintenance process ensures that
• 1) only legitimate changes are made to applications
• 2) such changes are also tested before being implemented.

• Auditor’s role in systems maintenance:

• The auditor’s review may extend into the maintenance phase to determine that
application integrity is still intact.

• Reason:
• An application’s integrity may have been compromised if it has undergone
maintenance (and even if it has not).
 Controlling Systems Maintenance
• The benefits achieved from controlling new system development can be quickly
lost during system maintenance if control does not continue into that phase.

• Two (2) Risks in System Maintenance:

• 1) programming errors that lead to financial misstatement
• Due to uncontrolled program changes
• Subtle programming errors  result in the creation and distribution of incorrect information
that goes undetected by the user.
• More apparent programming errors  result in system failures that can disrupt data
processing and even bring operations to a halt.
• 2) program fraud
• Due to an environment of poorly controlled maintenance which can go undetected for years.
 Controlling Systems Maintenance
• Controls: Two (2) controllable activities for systems maintenance
procedures:
• 1) Maintenance Authorization, Testing, and Documentation
• 2) Source Program Library Controls
 Controlling Systems Maintenance:
1) Maintenance Authorization, Testing, and Documentation
Maintenance activities should be given essentially the same treatment as new development.
All maintenance actions should require
Risks controls
• 1) Access to systems for • 1) formal authorization
• 2) technical specification of the changes
maintenance purposes increases
• 3) retesting the system
the possibility of systems errors.
• 4) updating the documentation.
• 2) Logic may be corrupted either
by the accidental introduction of • Additional controls for Extensive changes to
errors or intentional acts to program logic:
defraud. • 5) involvement by the internal auditor
• 6) implementation of user test and acceptance
procedures
 Controlling Systems Maintenance:
2) Access Control: Source Program Library
• Source program library (SPL) – magnetic disks that
are used to store application program source code.

• Risks: Application integrity can be jeopardized by

individuals who gain unauthorized access to
programs.

• The Worst-Case Situation: No Controls for SPL

• Control is always in conflict with operational
flexibility and efficiency.
• Systems professionals who must work daily within
this environment sometimes oppose controlling the
SPL.
 Controlling Systems Maintenance:
2) Access Control: Source Program Library
• Two (2) serious forms of exposure if SPL has no control:
• 1. Access to programs is completely unrestricted.
• Risk: No provision for detecting an unauthorized access.
• 2. Because of these control weaknesses, programs are subject to
unauthorized changes.
• Risk: With no provision for detecting unauthorized access to the SPL,
program integrity cannot be verified.
 Controlling Systems Maintenance:
2) Access Control: Source Program Library
• A Controlled SPL Environment
• SPL management system (SPLMS)
• Is used to control the SPL with protective
features and procedures.

• The black box surrounding the SPL

signifies the SPLMS.
 Controlling Systems Maintenance:
2) Access Control: Source Program Library
• SPLMS is used to control four routine but critical functions:
• (1) storing programs on the SPL
• (2) retrieving programs for maintenance purposes
• (3) deleting obsolete programs from the library
• (4) documenting program changes to provide an audit trail of the
changes.
 Controlling Systems Maintenance:
2) Access Control: Source Program Library
• Similarities between the SPL MS and a DBMS:
• SPLMS manages program files and DBMSs manage data files.

• Three (3) ways to acquire SPLMSs:

• 1) supplied by the computer manufacturer as part of the OS
• 2) purchased through software vendors
• 3) Developed by some organizations to provide special control features

• How to ensure program integrity?

• The mere presence of an SPLMS does not guarantee program integrity.
• An SPL requires specific planning and control techniques to ensure program integrity.
 Controlling Systems Maintenance:
2) Access Control: Source Program Library

• Five (5) control techniques for SPL:

• 1) Password Control
• 2) Separate Test Libraries.
• 3) Audit Trail and Management Reports.
• 4) Program Version Numbers.
• 5) Controlling Access to Maintenance Commands.
 Controlling Systems Maintenance:
2) Access Control: Source Program Library

• Five (5) control techniques for SPL:

• 1) Password Control
• A separate password for every program stored in the SPL.
• Only an authorized librarian has a direct access to the production SPL.
• Passwords to access programs can be changed regularly and disclosed only on
a need-to-know basis.
 Controlling Systems Maintenance:
2) Access Control: Source Program Library

• Five (5) control techniques for SPL:

• 2) Separate Test Libraries.
• Two (2) enhancements to this control feature:
• A) The creation of separate libraries (or directories) for each programmer.
• B) Program naming conventions as being either a test or a production
program.
 Controlling Systems Maintenance:
2) Access Control: Source Program Library

• Five (5) control techniques for SPL:

• 3) Audit Trail and Management Reports.
• Program modification reports
• an audit trail of program changes that can be reconciled against program maintenance
requests to verify that only changes requested and authorized were actually
implemented.
• can be produced as hard copy and on disk and can be governed by password control.
Controlling Systems Maintenance:
2) Access Control: Source Program Library
• Five (5) control techniques for SPL:
• 4) Program Version Numbers.
• This feature, when combined with audit trail reports, provides evidence for
identifying unauthorized changes to program modules.
• An unauthorized change is signaled by a version number on the production
load module that cannot be reconciled to the number of authorized changes.
• two possibilities explain this discrepancy:
• (1) authorized changes occurred that are unsupported by documentation or
(2) unauthorized changes were made to the program, which incremented the
version numbers.
Controlling Systems Maintenance:
2) Access Control: Source Program Library
• Five (5) control techniques for SPL:
• 5) Controlling Access to Maintenance Commands.
• maintenance commands
• Used by systems designers and administrators for legitimate technical reasons.
• Risks: The possibility of unrecorded, and unauthorized, program modifications.
• Controls:
• A) Maintenance commands should be password-controlled.
• B) The authority to use maintenance commands should be controlled by management or
the security group.