Lord, make me an instrument of your peace.

Where there is hatred, let me sow love.

Where there is injury, pardon.
Where there is doubt, faith.
Where there is despair, hope.
Where there is darkness, light.
Where there is sadness, joy.
O Lord, grant that I may not so much seek;
to be consoled, as to console;
to be understood, as to understand;
to be loved, as to love.
For it is in giving that we receive.
It is in forgiving that we are forgiven,
and it is in dying that we are born to Eternal Life.
Amen.
 XAUDCIS
HOLY ANGEL UNIVERSITY
 Controls and audit tests relevant to systems
development
 Risks and controls for program changes
 Auditing techniques (CAATTs) used to verify
application controls
 Auditing techniques used to perform substantive
tests in an IT environment
 Systems Professionals (for internally developed systems)
◦ Systems analysts
◦ Systems designers
◦ Programmers
 End Users
◦ Managers
◦ Operations personnel
◦ Accountants *
◦ Internal auditors *
 Stakeholders
◦ Accountants *
◦ Internal auditors *
Note Accountants & Internal
Auditors fill multiple roles.
◦ External auditors

4
 Creation/purchase of IS consumes
significant resources and has financial
resource implications.
 Quality of AISs and their output rests
directly on SDLC activities that produce
them.

5
 As Users
 As members of
development team
 As Auditors

6
 Systems Strategy
◦ Help reduce risk of creating unneeded,
unwanted, inefficient, ineffective systems
 Conceptual Design
◦ Control implications
◦ Auditability of system
 Systems Selection
◦ Economic feasibility

7
 IN HOUSE DEVELOPMENT
 COMMERCIAL SYSTEMS
 TRENDS IN COMMERCIAL SYSTEM
◦ Low Cost
◦ Emergence of Software Industry
◦ Growing Demand of Businesses
◦ Downsizing/ DDP IT Environment
 General
Turnkey Special Purpose
Accounting
Systems Systems
Systems

Office Vendor
Backbone
Automation Supported
Systems
Systems Systems

Advantages of Commercial Disadvantages of

Software Commercial Software

•Independence
•Implementation Time •The need for customized
•Cost systems (becomes dependent
•Reliability on vendor)
•Maintenance
Programming Test Results
& Testing

MAINTENANCE
 Objective of Systems Planning is to link individual projects or
applications to the strategic objectives of the firm.
 STEERING COMMITTEE & RESPONSIBILITIES (6)

 STRATEGIC SYSTEMS PLANNING – allocation, processing,

budgeting, informed decisions by systems specialists
1. A plan that changes constantly is better than no plan at all.
2. Strategic planning reduces the crisis component in systems
development.
3. Strategic systems planning provides authorization control for
the SDLC.
4. Cost Management
 Project Planning
 Project Proposal
 Project Schedule

 AUDITOR’S ROLE: Adequate Systems Planning

Takes Place
 1) The Survey Step & 2) Analysis of User’s
Need
 Serves as the foundation for the rest of SDLC
 The Survey Step
◦ Disadvantages
 Current Physical Tar Pit (sucked in & bogged down); Thinking
Inside the Box (improved current system rather radically new
approach)
◦ Advantages of Surveying Current System
 What old aspect should be kept, force analysis, Isolating the
root problem
GATHERING FACTS & FACTS GATHERING TECHNIQUES
Data Sources Data Stores Data Processes

Transaction
Data Flows Controls
Volumes

Bottlenecks
Error Rates Resource Costs and redundant
operations
 Observation Task Participation

Personal Interviews
• OPEN ENDED (allows to Reviewing Key
elaborate)
Documents
• QUESTIONNAIRES (more
specific, more detailed)
 Systems Analysis Report (pg 195)

 An accountant is a stakeholder, therefore it

should be involved in the analysis of needs of
the proposed system for advanced features.
 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
 Structured Design Approach (uses
Several alternatives that satisfy Identify/ compare all the
DFD) – Top Down; Starts with the
the system requirements during distinguishing features, input,
BIGGER PICTURE and then
system analysis (TWO process, output from one design
decomposed; uses data flow
APPROACHES) to another (figure 5.50)
diagrams

Object Oriented Approach (uses

Standard Components) ITERATIVE
APPROACH – reduced time for
cost dev’t, maintenance, testing
and improved user support &
flexibility
Auditor’s Role as a Stakeholder,
at least has an interest in the
conceptual design, because of the
impact on audit
Perform Detailed Feasibility Study
•Technical Feasibility – develop in existing technology
•Economic Feasibility – availability of funds
•Legal Feasibility – conflicts between conceptual concept & discharge liabilities
•Operational Feasibility - compatibility
•Schedule Feasibility- ability to implement w/in acceptable time

Perform Cost Benefit Analysis

•1. Identify Costs (One Time Costs vs Recurring Costs)
•2. Identify Benefits
•Tangible Benefits
•Intangible Benefits
•3. Compare Costs and Benefits
•NPV
•Payback Period
•Break Even Point
1) Escapable Costs
2) Interest Rates
3) One time & recurring Costs
4) Realistic Useful Lives
5) Intangible Values
 Detailed description of the proposed system satisfies
system requirements during Phase 2 & Phase 3.

 Perform System Design Walkthrough – Quality assurance

group

 Review System Documentation

◦ Inputs & source documents
◦ Outputs, reports & operational documents
◦ Normalized data for database tables
◦ Update data dictionary
◦ Processing logic or Flow Charts
 1) PROGRAM THE APPLICATION SYSTEM 2) TEST THE
APPLICATION SYSTEM
 Procedural Languages(Cobol, Fortran, C, PL1)
 Event Driven Languages- uses icons Microsoft VB; GUI
 Object Oriented Languages

 Programming the System-follow modular approach

regardless of the language used
1. Programming Efficiency
2. Maintenance Efficiency
3. Control
 2) Test the Application Software
 Testing Methodology
◦ Identifying programming & logical errors
 Testing Offline Before Deploying Online
◦ Never Ever Underestimate (Testing Environment vs Actual
Environment)
 Test Data
◦ Should be retained for reuse
◦ Serves as a frame of reference for auditor in designing and
evaluating future audit tests (i.e. the system has not
undergone any change)
 Complete engagement of programmers, users, designers, database administrators, users
and accountants
 Activities in this entail extensive costs
1. TESTING THE ENTIRE SYSTEM
◦ DOCUMENTING THE SYSTEM
 Designer & Programmer Documentation
 Operator Documentation
 User Documentation
 Novices
 Occasional Users
 Frequent Light Users
 Frequent Power Users
◦ USER HANDBOOK
◦ TUTORIALS
◦ HELP FEATURES
2. CONVERTING THE DATABASES
3. CONVERTING TO THE NEW SYSTEM
Cold Turkey Cutover – most risky; all at once
Phased Cutover- by modules; gradual
Parallel Operation Cutover – simultaneous; reconciliation
 THE AUDITOR’S ROLE IN SYSTEM
IMPLEMENTATION
1. Provide Technical Expertise
2. Specify Documentation Standards
3. Verify Control Adequacy & Compliance w/ SOX
POST IMPLEMENTATION REVIEW
4. Systems Design Adequacy
5. Accuracy of Time, Cost and Benefit Estimates
 Accommodate Changes in Users’ Needs
 It could be extensive
 Maintenance represents significant
outlay compared to initial development
costs.
 Last, longest and most costly phase of SDLC
◦ Up to 80-90% of entire cost of a system
 Audit Procedures:
◦ All maintenance actions should require
 Technical specifications
 Testing
 Documentation updates
 Formal authorizations for changes
 Systems Authorization
Activities
 User Specifications Activities
 Technical Design Activities
 Internal Audit Participation
 User Test and Acceptance
Procedure
Auditing objectives: ensure that...
◦ SDLC activities applied consistently and in
accordance with management’s policies
◦ system as originally implemented was free from
material errors and fraud
◦ 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
 Audit Procedures:
◦ New systems must be authorized.
◦ Feasibility studies conducted.
◦ User needs analyzed and addressed.
◦ Cost-benefit analysis completed.
◦ Proper documentation completed.
◦ All program modules thoroughly tested before implementation.
◦ Checklist of problems was kept.
◦ Systems documentation complies with organizational
requirements
 Maintenance Authorization, Testing & Documentation
 Source Program Library Controls – where application program
source code are stored
 SPL – No Controls
 Controlled SPLMS Environment
 1) Storing programs on the SPL
 2) Retrieving programs for maintenance purposes
 3) Deleting obsolete programs from lib
 4) Documenting program changes to provide audit trail of the
changes
◦ Password Control
◦ Separate Test Libraries
◦ Audit Trail & Management Reports
◦ Program Version Numbers
◦ Controlling Access to Maintenance Commands
 Auditor compares the current program version
number in the documentation file vs current
version number of the production program

 Auditor reconciles program maintenance

requests, program listings and program changes
to verify the need for and accuracy of program
 Figure 5.14
Auditing objectives: detect any unauthorized program maintenance and
determine that...
◦ maintenance procedures protect applications from
unauthorized changes
 Reconcile program version numbers
 Confirm maintenance authorization
◦ applications are free from material errors
 Reconcile the source code
 Review test results
 Retest the program
◦ program libraries (where programs are stored) are
protected from unauthorized access
 Review programmer authority table
 Test authority table
34