AUDITING SYSTEMS ACQUISITION /

DEVELOPMENT PROCESS

1
BUSINESS APLICATION SYSTEMS
Companies often commit significant IT resources (e.g. people,
applications, facilities and technology) to develop, acquire,
integrate and maintain application systems that are critical to
the effective functioning of key business processes.
These systems are critical information assets and should be
effectively managed and controlled.
In order to develop and implement these system different
activities/phases are performed (SDLC). Each step or phase in
the life cycle is an incremental step that lays the foundation
for the next phase, for effective management control in
building and operating Business Application Systems.

2
BUSINESS APLICATION SYSTEMS
A risk in any software development project is that the final
outcome may not meet all requirements. Problems due to
translation errors arise when initially defining the
requirements for interim products.
A variant of waterfall model normally involve a life cycle
verification approach that ensures that potential mistakes are
corrected early and not solely during final acceptance testing.
The verification and validation model , sometimes called the
V model also emphasizes the relationship between
development phases and testing levels.

3
4
From an IS auditor's perspective, the V Model's defined life
cycle phases and specific points for review and evaluation
provides the following advantages:
• The IS auditors influence is significantly increased when
there are formal procedures and guidelines identifying
each phase in the business application life cycle and the
extent of auditor involvement.
• The IS auditor can review all relevant areas and phases of
the systems development project, and report
independently to management.
• The IS auditor can identify selected parts of the system
and become involved in the technical aspects on the basis
of his/her skills and abilities.
• The IS auditor can provide an evaluation of the methods
and techniques applied through the development phases
5
of the business application life cycle.
ROLE OF IS AUDITORS IN SYSTEM DEVELOPMENT

The IS auditor's tasks in system development,

acquisition and maintenance may take place once the
project is finished or infrequently-during the project
itself. Tasks generally include the following:
 Meet with key systems development and user project
team members to determine the main components,
objectives and user requirements of the system and
to identify the areas that require controls.
 Discuss the selection of appropriate controls with
systems development and user project team
members to determine and rank the major risks to
and exposures of the system. 6
ROLE OF IS AUDITORS IN SYSTEM DEVELOPMENT
 Discuss references to authoritative sources with
systems development and user project team
members to identify controls to mitigate the risks to
and exposures of the system.
 Evaluate available controls and participate in
discussions with systems development and user
project team members to advise the project team
regarding the design of the system and
implementation of controls.
 Periodically meet with systems development and
user project team members, and review the
documentation and deliverables to monitor the
ROLE OF IS AUDITORS IN SYSTEM DEVELOPMENT

is to ensure that controls are implemented, user

and business requirements are met, and the
systems development/acquisition methodology is
being followed.
 IS Auditor also review and evaluate the application
system audit trails to ensure that documented
controls are in place to address all security, edit
and processing controls. Audit trails are tracking
mechanisms that can help IS auditors to ensure
program change accountability.

8
ROLE OF IS AUDITORS IN SYSTEM DEVELOPMENT
 Participate in post implementation reviews.
 Review appropriate documentation, discuss with key
personnel, and use observation to evaluate system
maintenance standards and procedures to ensure their
adequacy.
 Discuss and examine supporting records to test system
maintenance procedures to ensure that they are being
applied as described in the standards.
 Analyze test results and other audit evidence to
evaluate the system maintenance process to determine
whether control objectives were achieved.
 Identify and test existing controls to determine the
adequacy of production library security to ensure the
9
integrity of the production resources.
 FEASIBILITY STUDY
The IS auditor should perform the following functions:
 Review the documentation produced in this phase for
reasonableness.
 Determine whether all cost justifications/benefits are
verifiable and, showing the anticipated costs and
benefits to be realized.
 Identify and determine the criticality of the need.
 Determine if a solution can be achieved with systems
already in place. If not, review the evaluation of
alternative solutions for reasonableness.
 Determine the reasonableness of the chosen solution.
10
 REQUIREMENTS DEFINITION
The IS auditor should perform the following functions:
 Obtain the detailed requirements definition document and
verify its accuracy through interviews with the relevant user
departments.
 Identify the key team members on the project team and
verify that all affected user groups have/had appropriate
representation.
 Verify that project initiation and cost have received proper
management approval.
 Review the conceptual design specifications (e.g.
transforms, data descriptions) to ensure that they address
the needs of the user

11
 REQUIREMENTS DEFINITION

 Review the conceptual design to ensure that control

specifications have been defined.
 Determine whether a reasonable number of vendors
received a proposal covering the project scope and user
requirements.
 Review the UAT specification.
 Determine whether the application is a candidate for the
use of an embedded audit routine. If so, request that the
routine be incorporated in the conceptual design of the
system.

12
 SOFTWARE ACQUISITION PROCESS
The IS auditor should perform the following functions:
 Analyze the documentation from the feasibility study to determine
whether the decision to acquire a solution was appropriate.
 Review the RFP to ensure that it covers the items listed in this
section.
 Determine whether the selected vendor is supported by RFP
documentation.
 Attend agenda-based presentations and conference room pilots to
ensure that the system matches the vendor's response to the RFP.
 Review the vendor contract prior to its signing to ensure that it
includes the items listed.
 Ensure the contract is reviewed by legal counsel before it is signed.

13
 DETAILED DESIGN AND DEVELOPMENT
The IS auditor should perform the following functions:
Review the system flowcharts for adherence to the
general design. Verify that appropriate approvals
were obtained for any changes and all changes were
discussed and approved by appropriate user
management.
Review the input, processing and output controls
designed into the system for appropriateness,
Interview the key users of the system to determine
their understanding of how the system will operate,
and assess their level of input into the design of
screen formats and output reports.
14
 DETAILED DESIGN AND DEVELOPMENT
Assess the adequacy of audit trails to provide
traceability and accountability of system transactions.
Verify the integrity of key calculations and processes.
Verify that the system can identify and process
erroneous data correctly.
Review the quality assurance results of the programs
developed during this phase.
Verify that all recommended corrections to
programming errors were made and the
recommended audit trails or EAMs were coded into
the appropriate programs.

15
 SYSTEM TESTING
Testing is crucial· in determining the user requirements have
been validated, the system ·is performing as anticipated and
internal controls work as intended. Therefore it is essential
that IS Auditor be involved in reviewing this phase and
perform the following: .
• Review the test plan for completeness; indicate evidence
of user participation such as user development of test
scenarios and/or user sign-off of results; and consider
rerunning critical tests.
• Reconcile control totals and converted data,
• Review error reports for their precision in recognizing
erroneous data and resolution of errors.
• Verify cyclical processing for correctness (month-end, year-
16
end processing, etc.).
 SYSTEM TESTING
• Interview end users of the system for their understanding of
new methods, procedures and operating instructions.
• Review system and end· user documentation to determine
its completeness and verify its accuracy during the test
phase.
• Review parallel testing results for accuracy.
• Verify that system security is functioning as designed by
developing and executing access tests.
• Review unit and system test plans to determine whether
tests for internal controls are planned and performed.
• Review the user acceptance testing and ensure that the
accepted software has been delivered to the implementation
team. The vendor should not be able to replace this version.
• Review procedures used for recording and following through
17
on error reports.
 IMPLEMENTATION PHASE
This phase is initiated only after a successful testing phase.
The system should be installed according to the
organization's change control procedures. The IS auditor
should verify that appropriate sign-offs have been-obtained
prior to implementation and perform the following:
• Review the programmed procedures used for scheduling
and running the system along with system parameters
used in executing the production schedule.
• Review all system documentation to ensure its
completeness and that all recent updates from the
testing phase have been incorporated.
• Verify all data conversion to ensure that they are correct
and complete before implementing the system in
production. 18
 Documentation
 To ensure the effective utilization and future maintenance of
a system, it is important that all relevant system
documentation be updated.
 Due to light time constraints and limited resources, thorough
updates to documentation are often neglected.
 Documentation requiring revision may consist of program
and/or system flowcharts, program narratives, data
dictionaries, entity relationship models, data flow diagrams
(DFDs), operator run books and end-user procedural
manuals. Keeping the internal coherence of all these items is
a challenge; software configuration management packages
can be a valuable tool.
 Procedures should be in place to ensure that documentation
stored offsite for disaster recovery purposes is also updated.
19
This documentation is often overlooked.
 INFORMATION SYSTEMS MAINTENANCE PRACTICES

 System maintenance practices refer primarily to the

process managing change to application systems while
maintains the integrity of both the production source
code.
 Once a system is moved into production, it seldom
remains static. Change is expected in all systems
regardless of whether they are vendor-supplied or
internally developed. Reasons for change in normal
operations include internal lT /business Changes, new
external regulations changes in classification related to
sensitivity or criticality, audits and adverse incidents such
as intrusions and viruses.
20
 INFORMATION SYSTEMS MAINTENANCE PRACTICES

 To control the ongoing maintenance of the system, a

standard process for performing and recording changes
is necessary.
 This process, which usually mirrors the organization's
SDLC process, should include steps to ensure that the
system changes are appropriate to the needs of the
organization, appropriately authorized, documented,
thoroughly tested and approved by management.
 The process typically is established in the design phase
of the application when application system requirements
are baselined.
21
 CHANGE MANAGEMENT PROCESS OVERVIEW
Users should covey system change requests to the system
management using some type of formal correspondence such as
a standard change request form, memo or e-mail message.
At a minimum, the user request should include the requestor's
name, date of request, date the change is needed, priority of the
request, a thorough description of the change request, a
description of any anticipated effects on other systems or
programs, and fallback procedures in case the changes cause the
failure of the system.
The user could also provide a reason for the change, a cost
justification analysis and the expected benefits of the change. In
addition, the request should provide evidence that it has been
reviewed and authorized by user management. A signature on
the request form or memo typically provides this evidence.
22
 CHANGE MANAGEMENT PROCESS OVERVIEW
 Change requests should be in a format that ensures all
changes are considered for action and allows the system
management staff to easily track the status of the
request. This is usually done by assigning a unique control
number to each request and entering the change request
information into a computerized system. This can also be
performed manually. With detailed information regarding
each request, management can identify those requests
that have been completed and are still in progress or have
not been addressed yet.
 Management can also use this information to help ensure
that user requests are addressed in a timely manner. 23
 CHANGE MANAGEMENT PROCESS OVERVIEW

 All requests for changes and related information should be

maintained by the system maintenance staff as part of the
system's permanent documentation.
 Maintenance records of all program changes should exist
either manually or automatically.
 Several library management software products provide this
type of audit trail.
 The maintenance information usually consists of the
programmer ID, time and date of change, project or
request number associated with the change, and before
and after images of the lines of code that were changed.
24
 CHANGE MANAGEMENT PROCESS OVERVIEW
 This process becomes even more important when the
programmer who creates the program is also the
operator. In this case, it is assumed that the IS
department is either small or there are few applications
being processed. Special change management procedures
must be closely followed since segregation of duties
cannot be established in this environment and
compensating controls are required.
 It requires user management to pay more attention to
changes and upgrades made by the programmer, and
proper authorization must be given to the programmer
before putting any change into production.
25
 CHANGE MANAGEMENT PROCESS OVERVIEW
 In lieu of the manual process of management
approving changes before the programmer can submit
them into production, management could have
automated change control software installed to prevent
unauthorized program changes.
 By doing this the programmer is no longer responsible
for migrating changes into production.
 The change control software becomes the operator
that migrates programmer changes into production
based on approval by management.
 Programmers should not have write, modify or delete
access to production data. 26
 Testing Changed Programs
 Changed programs should be tested and also
eventually certified with the same discipline as newly
developed systems to ensure that the changes
perform the intended functions. In addition, if the risk
analysis determines it is necessary, additional testing
would be required to ensure:
– Existing functionality is not damaged by the change
– System performance is not degraded because of the change
– No security exposures have been created because of the
change

27
 Deploying Changes
 After the end user is satisfied with the system
test results and the adequacy of the system
documentation, approval should be obtained
from user management.
 User approval could be documented on the
original change request or in some other
fashion (memo or e- mail); however, evidence
that verifies user approval should be retained
by the system maintenance staff.
28
 LIBRARY CONTROL SOFWARES
The Library Control Procedure's primary purpose is
to provide protection & security for the source code
that is under development. In order to implement
these procedures Library Control Software are
developed to allow read-only access to source
code. These Software are used to ensure that only
authorized changes after getting required approval
are reflected in the codes being used in production
environment.

29
 Project Management
Project : A group of milestones or phases, activities
or tasks that support an effort to accomplish
something

• A dynamic process that utilizes the appropriate

resources of the organization in a controlled and
structured manner, to achieve some clearly defined
objectives identified as needs.
• It is always conducted within a defined set of
constraints
 PM Triple Constraints

• Time

• Cost

• Scope
Manage these or they will
manage you!
 ROLE OF IS AUDITORS IN PROJECT MANAGEMENT
 Throughout the project management process the
IS auditor should analyze the associated risks and
exposures inherent in each phase of the SDLC
and ensure that the appropriate control
mechanisms are in place to minimize these risks
in a cost-effective manner.
 Caution should be exercised to avoid
recommending controls that cost more to
administer than the associated risks they are
designed to minimize.

32
ROLE OF IS AUDITORS IN PROJECT MANAGEMENT
 When reviewing the SDLC process, the IS
auditor should obtain documentation from the
various phases and attend project team
meetings, offering advice to the project team
throughout the system development process.
The IS auditor should also assess the project
team’s ability to produce key deliverables by the
promised dates.

33
ROLE OF IS AUDITORS IN PROJECT MANAGEMENT
 Typically, the IS auditor should review the
adequacy of the following project management
activities:
– Levels of oversight by project committee/board
– Risk management methods within the project
– Issue management
– Cost management
– Processes for planning and dependency management
– Reporting processes to senior management
– Change control processes
– Stakeholder management involvement
34
 ROLE OF IS AUDITORS IN PROJECT MANAGEMENT
 Sign-off process- At a minimum, signed approvals from
systems development and user management
responsible for the cost of tile project and/or use of the
system Additionally, adequate and complete
documentation of all phases of the SDLC process should
be evident. Typical types of documentation may
include, but should not be limited to the following:
– Objectives defining what is to be accomplished during that
phase Key deliverables by phases with project personnel
assigned direct responsibilities for these deliverables
– A project schedule with highlighted dates for the completion
of key deliverables
– An economic forecast for that phase, defining resources and
the cost of tile resources required to complete the phase 35
 REVIEW OF THE PRACTICE OF PROJECT MANAGEMENT TOOLS
AND TECHNIQUES

 Project management is the application of knowledge, skills, tools

and techniques to a broad range of activities to achieve a stated
objective such as meeting the defined user requirements, budget
and deadlines for an IS project.
 Project management knowledge and practices are best described in
terms of their component processes of initiating, planning,
executing, controlling and closing a project. Overall characteristics
project planning are that it is a risk-based management process and
iterative in nature.
 Project management techniques also provide systematic
quantitative and qualitative approaches to software size estimating,
scheduling, allocating resources and measuring productivity.

36
 REVIEW OF THE PRACTICE OF PROJECT MANAGEMENT TOOLS
AND TECHNIQUES

 There are numerous project management techniques and

tools available to assist the project manager in controlling
the time and resources utilized in the development of a
system.
 The techniques and tools may vary from a simple manual
effort to a more elaborate computerized process.
 The size and complexity of the project may require
different approaches.
 These tools typically provide assistance in areas described
in the following sections.

37
 REVIEW OF THE PRACTICE OF PROJECT MANAGEMENT TOOLS AND
TECHNIQUES

 There are various elements of a project that should

always be taken into account.
 Project management should pay attention to three key
intertwining elements: deliverables, duration and budget
 Project duration and budget must be commensurate with
the nature and characteristics of the deliverables.
 In general, there will be a positive correlation between
highly demanding deliverables, a long duration and a high
budget.

38