Systems Development Controls &

Application Controls
Presented by: Luisito V. Correa Jr., CPA, CAT, MBA
Scope:
01 Systems Development Controls

 Controlling systems development activities

 Controlling program changes.

02 Application Controls

 Input controls
 Processing controls
 Output controls
Systems Development
Controls
CONTROLLING SYSTEMS
DEVELOPMENT ACTIVITIES
 CONTROLLING SYSTEMS DEVELOPMENT ACTIVITIES

Systems Authorization Activities

• All systems should be properly authorized.
• Users must submit requests to systems professionals in written form.

User Specification Activities

• Users need to be actively involved in the systems development process.
• User specification document - A detailed written description of user’s needs which
describe the user’s view of the problem. Users & systems professionals joint effort.
CONTROLLING SYSTEMS DEVELOPMENT ACTIVITIES

Technical Design Activities

• Translate user specifications into a set of detailed technical specifications for a
system that meets the user’s needs.
• The scope of these activities includes systems analysis, feasibility analysis, and
detailed systems design.
• The adequacy of these activities is measured by the quality of documentation.

Internal Audit Participation

• The internal auditor can play an important role in the control of systems
development activities.
• The internal auditor can serve as a liaison between users and the systems
professionals to ensure an effective transfer of knowledge.
CONTROLLING SYSTEMS DEVELOPMENT ACTIVITIES

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

User Test and Acceptance Procedures

• Many consider this to be the most important control over the systems development.
• The last point at which the user can determine the system’s acceptability prior to it
going into service.
• 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.
Audit Objectives Relating to Systems Development
The auditor’s objectives are to ensure that:
1) Systems development activities are applied
consistently and in accordance with management’s
policies to all systems development projects
2) The system as originally implemented was free from
material errors and fraud
3) The system was judged necessary and justified at
various checkpoints throughout the SDLC
4) System documentation is sufficiently accurate and
complete to facilitate audit and maintenance
activities.
Audit Procedures Relating to Systems Development
 The auditor should select a sample of completed and review the documentation for
evidence of compliance with stated systems development policies.

Specific points for review should include determining that:

• 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 conceptual designs.
• A cost-benefit analysis was conducted using reasonably accurate figures.
• The detailed design was an appropriate and accurate solution to the user’s problem.
• Test results show that the system was thoroughly tested.
• 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.
CONTROLLING PROGRAM
CHANGE ACTIVITIES
 CONTROLLING PROGRAM CHANGE ACTIVITIES

SOURCE PROGRAM LIBRARY CONTROLS

In larger computer systems, application program modules are stored in source code
form on magnetic disks called the source program library (SPL).

Executing a production application requires that the source code be compiled and
linked to a load module that the computer can process.
As a practical matter, programs in their compiled state are secure and free from
the threat of unauthorized modification.

Protecting the source code on the SPL is central to protecting the production
application.
 CONTROLLING PROGRAM CHANGE ACTIVITIES

A CONTROLLED SPL ENVIRONMENT

Controlling the SPL requires SPL management system (SPLMS) software.

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
(4) Documenting program changes to provide an audit trail of the changes.
CONTROLLING PROGRAM CHANGE ACTIVITIES
 CONTROLLING PROGRAM CHANGE ACTIVITIES

A CONTROLLED SPL ENVIRONMENT

Password Control
• Every financially significant program stored in the SPL can be assigned a
separate password.

Separation of Test Libraries

• Under this concept, a strict separation is maintained between the
production programs that are subject to maintenance in the SPL
and those being developed.
• Direct access to the production SPL is limited to a specific librarian
group that must approve all requests to modify, delete, and copy
programs.
 CONTROLLING PROGRAM CHANGE ACTIVITIES

A CONTROLLED SPL ENVIRONMENT

Audit Trail and Management Reports

• An important feature of SPL management software is the creation
of reports that enhance management control and support the audit
function.

Program Version Numbers

• The SPLMS assigns a version number automatically to each program
stored on the SPL.
• When programs are first placed in the libraries, they are assigned
version number zero. With each modification to the program, the
version number is increased by one.
 CONTROLLING PROGRAM CHANGE ACTIVITIES

A CONTROLLED SPL ENVIRONMENT

Controlling Access to Maintenance Commands
• Powerful maintenance commands are available for most library systems that
can be used to alter or eliminate program passwords, alter the program
version number, and temporarily modify a program without generating a
record of the modification.
• Access to the maintenance commands themselves should be password cont
rolled, and management or an IT security group should control the authority
to use them.
Audit Objectives Relating to Systems Maintenance

The auditor’s objectives are to determine that:

1) Maintenance procedures protect applications from unauthorized changes

2) Applications are free from material errors

3) Program libraries are protected from unauthorized access.

Audit Procedures for Identifying Unauthorized Program Changes

RECONCILE PROGRAM VERSION NUMBERS

CONFIRM MAINTENANCE AUTHORIZATION

Audit Procedures for Identifying Application Errors

RECONCILE THE SOURCE CODE

REVIEW THE TEST RESULTS

RETEST THE PROGRAM

Audit Procedures for Testing Access to Libraries

REVIEW PROGRAMMER AUTHORITY TABLES

TEST AUTHORITY TABLE

Application Controls
 Application Controls
 Application controls are associated with specific
applications (SAP B1, Oracle ERP, Quickbooks, etc.)

 These fall into three broad categories:

1. Input controls
2. Processing controls
3. Output controls.
INPUT CONTROLS
 Input controls are programmed procedures (routines)
that perform tests on transaction data to ensure that
they are free from errors.
 Input controls in real-time systems are placed at the
data collection stage to monitor data as they are
entered from terminals.
 In batch systems, input control tests are performed as
a separate procedure (or run) prior to the master file
update process.
 INPUT CONTROLS

Check digit
• A control digit is added to the code to detect data coding
errors.

• Two common classes of data input errors:

a) transcription errors
b) transposition errors.
Data Input Errors

1) Transcription errors
Illustration:
CUSTOMER ACCT NO.: 12345

123455 Addition error

1234 Truncation error

12845 Substitution error

Data Input Errors

2) Transposition errors

Illustration:
CUSTOMER ACCT NO.: 12345

12435 Single transposition

14325 Multiple transposition

 Check Digit

Using Modulus 11: CUSTOMER ACCT NO: 5372

Step 1: Weights: 5,4,3,2
1) Assign weights
Step 2: 5 x 5 = 25
2) Sum the products 3 x 4 = 12
7 x 3 = 21
3) Divide by the modulus 2x2= 4
62
4) Subtract the remainder from
Step 3: 62/11 = 5 r7
the modulus to obtain the
check digit Step 4: 11-7 = 4
5) Add the check digit to the Step 5:
original code to yield the new CUSTOMER ACCT NO: 53724
code
 Check Digit
Example: Sales clerk entered 53274 instead of 53724

Computer will reconcile the check digit.

5 x 5 = 25
3 x 4 = 12
2x3= 6
7 x 2 = 14
57
57/11 = 5 remainder 2

11-2 = 9

Conclusion: 9 should be the check digit of 53274 and not 4.

The system will detect the encoding error.
 INPUT CONTROLS

MISSING DATA CHECK

 INPUT CONTROLS
NUMERIC–ALPHABETIC CHECK
 INPUT CONTROLS

LIMIT CHECK
 INPUT CONTROLS

RANGE CHECK
 INPUT CONTROLS

REASONABLENESS CHECK
 INPUT CONTROLS

VALIDITY CHECK
PROCESSING CONTROLS
Batch Controls
Batch number

Batch date

Transaction code

Record count

Batch control total

Hash total
 Batch Controls

Batch date Transaction code

Batch number

Record
Hash total Batch Control total
count
Run-to-run control
• Run-to-run control is the use of
batch figures to monitor the batch
as it moves from one programmed
procedure (run) to another.

• At various points throughout

processing and at the end of
processing, the batch totals are
recalculated and compared to the
batch control record.

• This ensures that each run in the

system processes the batch
correctly and completely.
 Audit Trail Controls
TRANSACTION LOGS
Every transaction the system
successfully processes should be
recorded on a transaction log,
which serves as a journal.

LOG OF AUTOMATIC
TRANSACTIONS Audit
All internally generated transactions Trails
must be placed in a transaction log.

TRANSACTION LISTINGS
The system should produce a
(hard-copy) transaction listing of
all successful transactions.
OUTPUT CONTROLS
Output Controls
Output controls are a combination of programmed
routines and other procedures to ensure that system
output is not lost, misdirected, or corrupted and that
privacy is not violated.
 Controlling Hard-Copy Output

OUTPUT SPOOLING
In large-scale data processing
operations, output devices such as
line printers can become backlogged
with many programs simultaneously
demanding limited resources.

Applications are often designed to

direct their output to a magnetic
disk file rather than print it directly.
This is called SPOOLING.
 Controlling Hard-Copy Output

PRINT PROGRAMS

When a printer becomes available, the

print run program produces hard-copy
output from the output file.

Print program controls should be designed to deal

with two types of exposures present in this
environment:
1) The production of unauthorized copies of
output
2) Employee browsing of sensitive data.
 Controlling Hard-Copy Output

WASTE

Computer output waste is a potential source

of exposure.
Aborted reports and the carbon copies
from multipart paper need to be disposed of
properly.

From trash, computer criminals may obtain information

about a firm’s market research, credit ratings of its
customers, or trade secrets, which they can sell to a
competitor.
 Controlling Hard-Copy Output

REPORT DISTRIBUTION

The primary risks associated with the distribution

of sensitive reports include their being lost,
stolen, or misdirected in transit to the user.

The following control techniques can be used:

1) The reports may be placed in a secure mailbox to
which only the user has the key.
2) The user may be required to appear in person at the
distribution center and sign for the report.
3) A security officer or special courier may deliver the
report to the user.
 Controlling Hard-Copy Output

END-USER CONTROLS

Once in the hands of the user, output reports

should be examined for correctness.

Errors the user detects should be reported to the

appropriate computer services management.

Once a report has served its purpose, it should be

stored in a secure location until its retention period
has expired and then it should be shredded.
 Controlling Digital Output

Digital output controls

The primary output threat is the interception,

disruption, destruction, or corruption of the output
message as it passes across the communications
network.

Controls against exposures from equipment failure

- Parity check, echo check

Controls against exposures from subversive acts

- Encryption, digital envelope, digital signature, digital certificate
Thank you
and
God Bless!
End of Presentation