DOMAIN 3 – IS

ACQUISITION,
DEVELOPMENT &
IMPLEMENTATION
IT Auditing
OUTLINE
 3.0 Introduction
 3.1 Project governance and management
 3.2 Project management practices
 3.3 System development methodologies
 3.4 Control identification and design
 3.5 IS Implementation
 3.6 Data migration and conversion
 3.7 Post-implementation review
3.0 INTRODUCTION

 It is important that the IS auditor understand how an organization evaluate,

develop, implements, maintains and disposes of its information systems and
related component

 To provide assurance that an organization’s objectives are being met by the

management practices of its information
3.1 PROJECT GOVERNANCE AND MANAGEMENT

 To identify the relationships among projects, project portfolio and or a program

management, structure should be established

 This assists in:

 identifying common objectives for the business organization
 identifying and managing risk
 identifying resource connections

 All projects require governance structure, policies and procedures and specific control
mechanism to assure strategic and tactical alignment with the organization’s goals,
objectives and risk management activities
3.1.1 PROJECT MANAGEMENT PRACTICES
 Project management is the application of knowledge, skills, tools and
techniques to a broad range of activities to achieve a stated objectives such as
 meeting defined user requirements
 budget
 deadlines for an IS project

 A project is always a time-bound effort.

 A project has specific objectives and deliverables.

 Project management is a business process in a project –oriented organization.

3.1.1 PROJECT MANAGEMENT PRACTICES
 Project management process begins with the project charter and ends with the completion of
the project
 Project management knowledge and practice are best described in terms of their components
processes of :
 Initiating

 Planning

 Executing

 Controlling

 Closing
3.1.2 PROJECT MANAGEMENT STRUCTURE

 The project management approach is dependent on the size of the organization and
complexity of the business.
 Prior to project involvement, the IS auditor must become familiar with the standard or
structure used by the organization.
 IS auditor ensure that rules of system development, as they relate to segregation of duties and
responsibilities, are not compromised.
 Request for a major projects should be submitted to and prioritized by and IT steering
committee.
 The committee identifies a project manager
 Project manager takes control over the project and be allocated the appropriate resources for
the successful completion of the project
 3.1.2 PROJECT MANAGEMENT STRUCTURE
Outlines the authority and control within an organization:
1. Influential-structure organization: The project manager has only a staff function without
formal management authority.

2. Project-structured organization: The project manager has formal authority over those taking
part in the project. Includes authority over budget, schedule and team

3. Matrix-structured project organization: Management authority is shared between the

project manager and the department heads.

 For an IS auditor, it is important to understand these forms and their implications on controls
in project management activities.

 Requests for major projects should be submitted to and prioritized by the IT steering
committee.
 3.1.2 PROJECT MANAGEMENT STRUCTURE

 IS auditor may be included in the project team as control experts.

 In such cases, IS auditors are not performing an audit, but are participating on the project in an
advisory role.

 Depending on the level of involvement, auditor become ineligible to perform audit of the
application when it becomes operational.
3.1.2 PROJECT MANAGEMENT STRUCTURE
3.1.3. PORTFOLIO / PROGRAM MANAGEMENT
A Program:
A group of projects and time-bound tasks that are closely linked together through
 common objectives,
 common budget,
 intertwined schedules and
 strategies

A Portfolio:
All of the projects (related or unrelated) being carried out in an organization at a given point in time to
facilitate effective management of that work to meet strategic business objectives.

 Portfolio, Programs and projects are often controlled by a project management office (PMO), which
governs the processes of project management but are not typically involved in the management of the
content
 Programs are more complex, usually have longer duration, a higher budget and higher risk associated with
them
3.1.3. PORTFOLIO / PROGRAM MANAGEMENT

 The objectives of project portfolio management are:

 Optimization of the results of the project portfolio (Minimize Risk and maximize Resources)
 Prioritizing and scheduling projects
 Resource coordination (internal and external)
 Knowledge transfer through the projects

 A project portfolio database is mandatory for project portfolio management that include:
 project owner
 schedule
 objectives
 project type
 status
 cost

 A Portfolio Manager is a professional who is responsible for making investment

decisions and carrying out investment activities on behalf of individuals or institutions.
3.1.3. PORTFOLIO / PROGRAM MANAGEMENT

Example:
 A. An organization is migrating from legacy application to an ERP system and has the
strategic goal of delivering cutting-edge computers and maintaining high cash flow to continue
to fund research and development.
 To do so the organization is using its:
 1. Internal pool of application developers to code its strategic business process of manufacture of
newly designed computers to deliver finished goods and sales order to cash receipts considering the
sensitivity of its business model
 2. Vendors to code the nonstrategic business processes of procure to pay and financial accounting

 B. the organization is also pursuing a program for outsourcing transactional process to a third-
party service provider for online sale and a payment portal

 Determine the projects, programs and portfolio?

3.1.4. PROJECT BENEFIT REALIZATION

 A way to measure how IT and business add true value to the enterprise.

 Benefit realization objectives:

 Ensure that IT and the business fulfill their value management responsibilities
 IT investment achieve the promised benefits and deliver measurable business value
 Required capabilities (solutions and services) are delivered:
 On time
 Within budget

 IT services and other IT assets continue to contribute to business value

3.1.4. PROJECT BENEFIT REALIZATION

 Benefit realization at the project

level considers the total business
benefits and total business costs
through the life of the new system

 Encompasses 4 phases:
 3.1.4. PROJECT BENEFIT REALIZATION

 IS auditor should understand how the business defines value or a return on investment (RIO) for
developing projects
 If an organization fails to meet it RIO objectives, weakness are in its SDLC and related management
practices
 Assessment of the benefits realization processes and the business case should be a key element of
benefits realization processes

Business case development and feasibility study:

 A business case provides the information required for an organization to decide whether a project should proceed.
 It allows for a comparison of costs and business benefits and provides justification for setting up or continuing a
project.
 The business case should answer the question, “Why should this project be undertaken”.
 After business case we conduct feasibility study.

Project benefits realization must be part of the governance and management of a project
 3.1.4. PROJECT BENEFIT REALIZATION

Business case development and feasibility study:

 An assessment of the practicality of a proposed plan or method (Is this feasible?).
 The feasibility study will normally include the following six steps:
3.1.4. PROJECT BENEFIT REALIZATION

During the feasibility study, the IS auditor should perform the following:

 Review the documentation for the phase to ensure that it is reasonable.

 Determine whether all cost justifications/benefits are verifiable and that they show the
anticipated costs and expected benefits.

 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 suitability of the chosen solution

3.1.5. PROJECT OBJECTIVES
 Project objectives are the specific action statements that support the project goals.

 Project objectives should always begin with an action verb.

 A project needs clearly defined results that are: SMART

Specific,
Measurable,
Attainable,
Realistic and
Timely
3.1.5. PROJECT OBJECTIVES

 A commonly accepted approach to define project objectives is to start with an object

breakdown structure (OBS), then work breakdown structure (WBS) and then work packages
(WP).

OBS: A structure that represents the individual components of the solution and their
relationships to each other in a hierarchical manner, either graphically or in a table.

WBS: Designed after the OBS has been compiled, this structures all the tasks that are necessary
to build up the elements of the OBS during the project.

WP: Detailed specification regarding WBS can be found in WPs.

3.1.5. PROJECT OBJECTIVES
3.2. PROJECT MANAGEMENT PRACTICES
 Project management is the application of knowledge, skills, tolls and techniques to a broad range of
activities to achieve a stated objectives such as meeting the defines user requirements, budget and
deadlines for an IS project.

 Project management knowledge and practices are best described in term of their component processes of:
 Initiating
 Planning
 Execution
 Controlling
 Closing a project

 Project management should pay attention to

three key intertwining elements:

1. Cost 2. Duration 3. Budget
3.2.1. PROJECT INITIATION

 Project initiation is the starting point of any project.

 A project will be initiated by project manager or project sponsor.

 Documents called “Term of reference” or “Project charter” states the objectives of the project,
the stakeholders in the system to be produces and the project manager and sponsor.

 Approval of project initiation document (PID) or a project document (PD) is the authorization
for a project to begin.
3.2.1. PROJECT INITIATION

The initiation of a project may be achieved by:

 One-on-one meetings

 Kick off meetings

 Project start workshop

 A combination of the three

3.2.2. PROJECT PLANNING
 Project planning is one of the main project management processes.
 Adequate planning leads to the correct completion of work.
 There are some techniques that are useful in creating a project plan and monitoring its progress
throughout the execution of the project to provide continual support for making it successful.

A. System Development Project Cost Estimation:

Four commonly used methodologies to estimate the cost of system development project are:
1. Analogous Estimation (from prior project)
2. Parametric Estimation (employee hours, materials, technologies…etc. More accurate)
3. Bottom-up Estimation (cost of each activity. Most accurate but time consuming)
4. Actual Estimation (same system during past projects)
3.2.2. PROJECT PLANNING

B. Software Size Estimation:

 Relates to methods of determining the relative physical size of the application software to be
developed.
 Guide to the allocation of resources and to judge the time and cost required for its
development and to compare the total effort required by the resources.

Function Point Analysis: A multiple-point technique widely used for estimating complexity in
developing large business applications.
The results of FPA are a measure of the size of an IS based on the complexity of the
Input, output, interface, files and enquires with which user sees and interacts
3.2.2. PROJECT PLANNING

C. Software Cost Estimation:

 Cost estimation is a results of software size estimation.
 Automated techniques are available for cost estimation of project of each phase of system
development.

 To use these tools, a system is divided into main components, i.e.

- Source code language

- Main storage Constraints
- Data Storage Constraints
- Computer Access
- The target machine used for development
- The security Environment
- Staff Experience
3.2.2. PROJECT PLANNING

D. Scheduling and Establishing the Time Frame

Gantt Chart: Chart that aids in the scheduling of activities needed to complete a project; shows when an
activity should begin and when it should end along a timeline.

Critical Path Methodology (CPM): The sequence of activities whose sum of activity time is longer than
that for any other path through the network; if everything goes according to schedule, the duration gives the
shortest possible completion time for the overall project.

Program Evaluation Review Technique (PERT Chart): Technique that uses three different estimates of
each activity duration instead of using a single number for each activity duration (as used by CPM); the
three estimates are then reduced to a single number and then the classic CPM algorithm is applied.
(used with uncertainty about the duration)

Timebox Management: A project management technique for defining and deploying software deliverables
within a relatively short and fixed period of time, and with predetermined specific resources (for
prototyping or rapid application development)
GANTT CHART SAMPLE
WHO’S STUCK WITH THE GORILLA
THIS WEEK?
3.2.3. PROJECT EXECUTION

 After all paperwork is done, in this phase, the project management executes the project in
order to achieve project objectives.

 Each member of the team carries out their own assignments within the given deadline for each
activity.

 The detailed project schedule will be used for tracking the project progress.

 During the project execution, there are many reporting activities to be done. The senior
management of the company will require daily or weekly status updates on the project
progress.
3.2.4. PROJECT CONTROLLING AND MONITORING

 During the project life cycle, the project activities should be thoroughly controlled and
validated.
 The controlling can be mainly done by adhering to the initial protocols such as project plan,
quality assurance test plan and communication plan for the project.

A. Management of Scope Changes:

 This process start with a formal change request that contains a clear description of the
requested changes and the reason for change.
 Change requests must be submitted to the project manager.
 If changes are accepted, plan should be updated to reflect requested change.
3.2.4. PROJECT CONTROLLING AND MONITORING

B. Management of Resource Usage:

 The process by which the project budget is being spent.
 To determine whether actual spending is in line with planned spending
 Resource usage must be measured and reported
 A technique called Earned Value Analysis (EVA) is used for managing resource usage.

Earned Value Analysis: Consists of comparing the metrics at regular intervals during the
project:
 budget to date
 actual spending to date
 estimate to complete (cost required to complete the remaining work)
 estimate at completion (total cost of the project at the end)
3.2.5. PROJECT CONTROLLING AND MONITORING
C. Management of Risk
 Risk is defined as a possible negative event or condition that would disrupt relevant aspect of
the project.
 There are two categories of project risk:

1. category that impact business benefits

2. category that impact the project itself.
 Project sponsor is responsible for mitigating the first category of risk and project manager is
responsible for mitigation of second category of risk.
 Risk management process steps are:

1. Identifying risk 2. Assess and evaluate risk

3. Manage risk 4. Monitor risk
5. Evaluate the risk management process
3.2.6. PROJECT CLOSING
 At some point, the project is closed and the new or modified system is handed over to the
users and/or system support staff.

Post project Review: Formal process in which lessons learned and an assessment of project
management processes used are documented to allow reference, in the future, by other project
managers or users working on projects of similar size and scope.

Post Implementation Review: Process typically completed once the project has been in use for
some time - long enough to realize its business benefits and costs, and measure the project's
overall success and impact on the business units.
3.3. SYSTEM DEVELOPMENT METHODOLOGIES

Is a structure that an organization uses to plan and control the:

 Development of ISs

 Software

 New business applications

3.3.1. BUSINESS APPLICATION DEVELOPMENT
Two major categories include:
Organization-centric: Objective is to collect, collate, store, archive and share information with
business users and various applicable support functions

End user-centric: Objective is to provide different views of data for their performance
optimization. The objective includes decision support system DSS and geographic information
systems GIS.

 Companies commit significant IT resources to develop, acquire, integrate and maintain

application systems that are critical to effective functioning of key business processes/drivers.
3.3.1. BUSINESS APPLICATION DEVELOPMENT

Key Business Drivers: The attributes of a business function that drive the behavior and
implementation of that business function to achieve the strategic business goals of the
company.

 A risk in software development project is that the final outcome may not meet all
requirements.
3.3.2. SDLC MODELS
Traditional SDLC Approach
 Also the various phases of a project can be completed sequentially - one phase called waterfall
model.
 SDLC phases are:

1. Feasibility study
2. Requirements definition
3A. Software Selection and Acquisition (purchased systems)
3B. Design (in-house development)
4A. Configuration (purchased system)
4B. Development (in-house system)
5. Final Testing and Implementation
6. Post implementation
 3.3.2. SDLC MODELS
Verification and validation Model (V Model): Modified Waterfall model that provides for
back references for VERIFICATION and VALIDATION
3.3.3. SDLC PHASES
Phase 1. Feasibility study: A study concerned with analyzing the benefits and solutions for the
identified problem area. This include the development of business case that states the strategic benefits.

Phase 2. Requirements Definition: Concerned with identifying and specifying the business
requirements of the system chosen for development during the feasibility study.

Phase 3A. Software Selection and Acquisition:

 To evaluate the risk and benefits of developing new system versus acquiring from a vendor a suitable
system that is complete, tested and proven.
 The decision is based on various factors i.e. cost, availability and gap between development and
acquisition.
 Software acquisition is the process that should occur after the requirements definition phase
 Users must be involved in the package evaluation and selection process if it is going to be provided
by a specific vendor
3.3.3. SDLC PHASES
Request for Proposal (RFP): Written request asking contractors to propose solutions and
prices that fit customer's requirements; this method is more applicable in system integration
projects when the requirement is more toward a solution and related support and maintenance.

Invitation to Tender: written request asking contractors to propose solutions and prices that fit
customer's requirements; this method is more applicable where procurement of hardware,
network, database, etc. is involved and when the product and related services are known in
advance.
3.3.3. SDLC PHASES
Request for Proposal (RFP) Contents:
1. Product vs. System Requirements
2. Product Scalability and Interoperability
3. Customer References
4. Vendor Viability / Financial Stability
5. Availability of complete and reliable documentation
6. Vendor Support
7. Source Code Availability
8. No. of years of experience in offering the product
9. A recent or planned enhancements to the product with dates
10. No. of client sites using the product with list of current users
11. Acceptance test of the product
3.3.3. SDLC PHASES
Role of Auditor:

 IS Auditor is involved in the software acquisition process to determine whether an adequate

level of security controls have been considered prior to any agreement being signed.

 If no security controls are there, it may become difficult to ensure data integrity for the
information that will be processed through the system.
3.3.3. SDLC PHASES
Phase 3B. Design
 Based on the requirements definition phase, a detail design should be developed.
 Define how the system will satisfy requirements

Entity Relationship Diagram (ERD): These diagrams show how the entities that make up a
relational database are linked together. Using cardinality the relationships are displayed using a
straight line to link the entities, which are represented by a rectangle.

IS Auditor’s Role:
 To verify whether an adequate system of controls are incorporated into system specifications
and test plan.
 The key documents coming out of this phase include system, subsystem, program and
database specification, test plans and a defined and documented formal software change
control process.
3.3.3. SDLC PHASES
3.3.3. SDLC PHASES
Phase 4A. Configuration:
 System configuration consists of defining, tracking and controlling changes in an acquired
system to meet the need of business.

 For ERP systems, the tasks involve the modification of configuration tables as well as some
development, primarily to ensure that the ERP system is integrated into the existing IT
architecture.

 System configuration is supported by change management policies and processes.

3.3.3. SDLC PHASES
Phase 4B. Development:

 Uses the detailed design developed in phase 3B.

 Design to begin coding, moving the system one step closer to a final product.

Programming Methods and techniques

Programming Languages
Program Debugging
3.3.3. SDLC PHASES
Phase 5. Final testing and Implementation:
 The actual operation of the new information system is established and tested.
 Next step is to perform site acceptance testing, which is a full system test conducted on the
actual operations environment.
3.3.3. SDLC PHASES
Phase 6. Post Implementation Review:

Post project review: Internal review to assess and critique the project process

Post implementation review: Review to assess and measure the value the project has on the
business (benefits realization)
3.5.4. RISK ASSOCIATED WITH SOFTWARE DEVELOPMENT

Business risk:
Risk related to the likelihood that the new system may not meet the users' business needs,
requirements and expectations.

Project risk:
Risk that the project activities to design and develop the system exceed the limits of the financial
resources set aside for the project and, as a result, it may be completed late, if ever.
3.3.5. SOFTWARE DEVELOPMENT METHOD
1. Agile Development:
A family of similar development processes that espouse a nontraditional way of developing
complex systems.
These processes are termed “agile” because they are designed to flexibly handle changes to the
system being developed or the project that is performing the development.

2. Prototyping – Evolutionary Development:

The process of quickly putting together a working model (a prototype) in order to test various
aspects of a design, illustrate ideas or features and gather early user feedback.
Prototyping uses programmed simulation techniques to represent a model of the final system to
the user for advisement and critique. The emphasis is on end-user screens and reports. Internal
controls are not a priority item since this is only a model.
3.3.5. SOFTWARE DEVELOPMENT METHOD
3. Rapid Application Development (RAD):
A methodology that enables enterprises to develop strategically important systems faster, while
reducing development costs and maintaining quality by using a series of proven application
development techniques, within a well-defined methodology.

4. Object Oriented System Development:

OOSD is a programming technique that groups data and procedures into objects, which permits
analysts, developers and programmers to consider larger logical chunks of a system and clarify
the programming process.
OOSD allows for the management of an unrestricted variety of data, the ability to model
complex relationships and the ability to meet demands of a changing environment.
3.3.5. SOFTWARE DEVELOPMENT METHOD
5. Component Based Development:
 This method assembles applications from cooperating packages of executable software that
make their services available through defined interfaces.

 It reduces development time and cost, improves quality, promotes modularity and simplifies
reuse.

6. Web-Based Application Development:

 This approach uses XML languages (SOAP, WSDL, UDDI) to provide more effective
integration of code modules within and between enterprises.
3.3.5. SOFTWARE DEVELOPMENT METHOD
7. Software Reengineering:
This is a process involving the extraction of components from existing systems and
restructuring these components to develop new systems or to enhance the efficiency of existing
systems.
Existing software systems thus can be modernized to prolong their functionality.

8. Reverse Engineering:
Studying and analyzing an application or a SW to see how its functions and develop a similar
system
This is a software engineering technique whereby existing application system code can be
redesigned and coded
3.3.5. SOFTWARE DEVELOPMENT METHOD
9. Business process reengineering (BPR)
 Business process reengineering is the act of recreating a core business process with the goal of improving
product output, quality, or reducing costs.
 It is usually done by automating system processes
 BPR involve the following steps:
Step 1: Define the area to be reviewed
Step 2: Develop a project plan
Step 3: Gain an understanding of the process under review
Step 4: Redesign and streamline the process
Step 5: Implement and monitor the new process
Step 6: Establish a continuous improvement process

10. Benchmarking:
 About improving business processes
 It’s a BPR method for improvement
 A continuous, systematic process for evaluating the products, services, or work processes of organizations
recognized as a world-class "reference" in a globalized world
 3.3.6 SYSTEM DEVELOPMENT TOOLS

Computer-aided software engineering (CASE)

 The use of automated tools to aid in the software development process
 For software requirements capture and analysis, software design, code production, testing, document
generation….etc.

Code generators
 Tools, often incorporated with CASE products, that generate program code based on parameters
defined by a systems analyst or on data/entity flow diagrams developed by the design module of a
CASE product

Fourth-generation language 4GL:

 Nonprocedural language that enables users and programmers to access data in a database
3.3.7. INFRASTRUCTURE
DEVELOPMENT/ACQUISITION PRACTICES
 Organizations are acquiring new infrastructure depending on the requirements.

 Physical architecture analysis: is the definition of component and the necessary road map to move
from one to the other.

 It is important and its impact is not only economic (money) but with many other choices such as
operational procedures, training needs and installation issues.

 Physical architecture analysis cannot be only based on price, reasoned choice must be made.

 Successfully analyze the existing architecture

 To design a new architecture that takes into account the existing architecture, scalability, reduce costs,
increased functionality, security and confidentiality issues are factors that must be considered
3.3.7. INFRASTRUCTURE
DEVELOPMENT/ACQUISITION
Infrastructure acquisition has the following steps:
PRACTICES
Project Phases of Physical Architecture Analysis:
1. Review of existing architecture
2. Analysis and design
3. Draft functional requirements
4. Functional requirements (presentation/discussion)
5. Define final functional requirements
6. Proof of concept (delivery of prototype)
(Vendor selection throughout phases 1-5)

Project Phases of Planning the Implementation of Infrastructure

1. Procurement phase
2. Delivery time
3. Installation plan
4. Installation test plan
(Requirements analysis throughout steps 1-4)
3.3.8. HARDWARE ACQUISITION
 The selection of computer hardware requires the organization to define specifications for
outside vendors.
 These specifications should be used in evaluating vendor-proposed solutions.
 This specification is sometimes called an invitation to tender (ITT) or a request for proposal
(RFP).

 IS auditor role in HW acquisition

 Determine if the acquisition process began with a business need
 Determine if several vendors were considered and whether the comparison between them
was done according to the required criteria
3.3.9. SYSTEM SOFTWARE ACQUISITION

Number of business issues must be considered in selecting system software, i.e.

 Business, functional and technical needs and specifications

 Cost and benefits
 Compatibility with existing systems
 Security
 Training and hiring staff
 Future growth needs
 Impact on the system and network performance
 Open source code vs. proprietary code
3.3.9. SYSTEM SOFTWARE ACQUISITION

IS auditor role in SW acquisition

 Analyze the documentation from the feasibility study to determine whether the decision to
acquire a solution was appropriate
 Review the request for proposal (RFP) to ensure that it covers all the items
 Determine whether the selected vendor is supported by RFP documentation
 Review vendors contract prior to its signing to ensure that it includes all the RFP items
 Ensure the contract is reviewed by legal counsel before it is singed
 Review RFP to ensure security responses are included by the vendor
3.4 CONTROL IDENTIFICATION AND DESIGN

IS auditor must:

1. Identify and understand controls designed to ensure the authorization, accuracy and

completeness of data input to, processing by and output from various business and
computer applications

2. Be familiar with controls techniques

3.4.1. INPUT/ORIGINATING CONTROLS

 Input controls ensure that only authorized, accurate and complete information are input and that these
transactions are only processed once.

Input Authorization
 Input authorization verifies that all transactions have been authorized and approved by management.
 Helps ensure that only authorized data are entered for processing by application.
 Types of authorization include:
 Management signatures on batch forms or source documents (evidence of authorization)
 Online access controls
 Unique passwords
 Terminal or client workstation identification (serial number)
 A well-designed source documents
 Input data validation
3.4.1. INPUT/ORIGINATING CONTROLS

Error Reporting and Handling

 Input error handling verifies that only correct data is accepted into a system. It can be processed by the
following:

 Rejecting only transactions with errors (the rest would be processed)

 Rejecting the whole batch of transactions (for correction before processing)
 Holding the batch in suspense (pending correction)
 Accepting the batch and flagging error transactions (error data processed and flagged for
identification, enabling error correction)
Input control3.4.1.techniques
INPUT/ORIGINATINGinclude:
CONTROLS

 Transaction log: Contains a detailed list of all updates.

A transaction log can be reconciled to the number of source documents received to verify that all
transactions have been input.
 Reconciliation of data: Controls whether all data received are properly recorded and processed.
 Documentation: Written evidence of user, data entry and data control procedures.
 Error correction procedures: These include:

- Logging of errors - Suspense file

- Timely correction - Error file
- Upstream re-submission - Validity of correction
- Approval of correction
 Transmittal Log: Documents transmission or receipt of data
 Cancellation of source documents: Procedures to cancel source documents such as by punching with holes or
making them to avoid duplicate entry.
 3.4.2. PROCESSING PROCEDURES AND CONTROLS

Ensure reliability of application program processing.

 IS auditor need to understand these procedures and controls.

Data Validation and Editing Procedures

 Ensure that input data are validated and edited as close to the time of origination
 Edit controls are preventive controls that are used in a program before data are processed. Some of
the data validation edit controls are:
- Sequence check - Limit check - Range check
- Validity check - Reasonableness check - Table lookups
- Existence check - Check digit - Logical relationship check
- Completeness check - Duplicate check
 3.4.2. PROCESSING PROCEDURES AND CONTROLS

Processing controls:
 Ensure the completeness and accuracy of accumulated data.
 They ensure that data in a file/database remain complete and accurate until changed as a result of authorized processing
or modification routines.
 Control techniques to address the issues of completeness and accuracy of data.

- Manual recalculation (ensure processing is accomplishing the anticipated task )

- Editing (program instruction/subroutine tests the accuracy, completeness and validity of data)
- Run-to-run total (ensures data read into the computer were accepted and then processed)
- Program controls (SW detects and initiate corrective action for errors in data processing)
- Reasonable verification of calculated amount (application verifies the reasonableness)
- Limit check on amounts (amount calculated correctly via the use of predetermined limit)
- Reconciliation of file totals (through the use of a file control record, or an independent control file)
- Exception reports (program identifies transactions/data that appears to be incorrect )
3.4.2. PROCESSING PROCEDURES AND CONTROLS

Data File Control Procedures

 Data file controls ensure that only authorized processing occurs to stored data.
 Before and after transaction image reporting
 Maintenance error reporting and handling
 Source documentation retention
 Internal and external labeling
 Version usage
 Data file security
 One-for-one checking
 Prerecorded input
 Transaction logs
 File updating and maintenance authorization
 Parity checking
3.4.3. OUTPUT CONTROLS

Output controls provide assurance that the data delivered to users will be presented, formatted
and delivered in a consistent and secure manner. Controls includes:

 Logging and storage of negotiable, sensitive and critical forms in a secure place
 Computer generation of negotiable instruments, forms and signatures
 Report accuracy, completeness and timeliness
 Reports generated from the system
 Report distribution
 Balancing and reconciling
 Output error handling
 Output report retention
 Verification of receipt of reports
3.4.4. APPLICATION CONTROLS

Are controls over input, processing and output functions

Application controls ensure that:
 Only complete, accurate and valid data are entered and updated in a computer system.
 Processing accomplishes the correct task.
 Processing results meet expectations.
 Data are maintained
3.4.4. APPLICATION CONTROLS

IS Auditor’s role in reviewing application controls:

 Identifying significant application components and the flow of transactions

 Identifying the application control strengths and evaluating the impact of the control
weaknesses
 Developing a testing strategy
 Testing the controls to ensure their functionality and effectiveness
 Evaluating the control environment by analyzing the test results and other audit evidence to
determine that control objectives were achieved
 Considering the operational aspects of the application to ensure its efficiency and effectiveness
3.4.4. APPLICATION CONTROLS

Flow of transactions through the system

 A transaction flowchart provides information regarding key processing
controls.

Risk Assessment Model to Analyze Application Controls

(Already discussed in Domain 1)
3.4.4. APPLICATION CONTROLS

Observing and Testing User Performing Procedures

Segregation of duties - Implementing control procedures to clearly divide authority and

responsibility within the information system function to prevent employees from perpetrating
and concealing fraud
IS IMPLEMENTATION
3.5 IS IMPLEMENTATION

IS implementation is when the system is installed and moved into the production
environment after appropriate system and users’ acceptance testing
3.5.1 TESTING METHODOLOGY

Testing:

 Verifies and validates that a program, subsystem or application performs the

functions for which it has been designed.

 IS auditor can play preventive or detective role in testing process.

 3.5.2 TESTING CLASSIFICATIONS
1. Unit Test: Testing of an individual program or module.
2. Interface or integration testing: A hardware or software test that evaluates the connection of
two or more components that pass information from one area to another.
3. System Testing: A series of tests designed to ensure that modified programs, objects, database
schema, etc., which collectively constitute a new or modified system, function properly.

3.1. Recovery testing: Checking the system's ability to recover after a software or hardware
failure.

3.2. Security testing: Making sure that the modified/new system includes provisions for
appropriate access controls and does not introduce any security holes that might compromise
other systems.
3.5.2 TESTING CLASSIFICATIONS
3.3. Load testing: Testing an application with large quantities of data to evaluate its
performance during peak hours.

3.4. Volume testing: Studying the impact on the application by testing with an incremental
volume of records to determine the maximum volume of records (data) that the application can
process.

3.5. Stress testing: Studying the impact on the application by testing with an incremental
number of concurrent users/services on the application to determine the maximum number of
concurrent users/services the application can process; should be carried out in a test
environment using live workloads.

3.6. Performance testing: Comparing the system's performance to other equivalent systems
using well-defined benchmarks.
3.5.2 TESTING CLASSIFICATIONS
4. Final Acceptance Test:

4.1. Quality assurance testing (QAT): Testing that focuses on the documented specifications and the
technology employed; verifies that the application works as documented by testing the logical design and the
technology itself.

4.2. User acceptance testing (UAT): Testing that supports the process of ensuring that the system is
production-ready and satisfies all documented requirements; focuses on functional aspect of the application.

IS Auditor Role:
When tests are completed, the IS auditor should issue an opinion to management as to whether the
system meets the business requirements, has implemented appropriate controls and is ready to be
migrated to production.

This report should also specify the deficiencies in the system that need to be corrected and should
identify and explain the risk that organization is taking by implementing new system.
 3.5.2 TESTING CLASSIFICATIONS
Other types of Testing:
Alpha testing: testing that is performed only by users within the organization developing the software.

Beta testing: a form of user acceptance testing that generally involves a limited number of external users.

Pilot testing: preliminary test that focuses on specific and predetermined aspects of a system; provides a
limited evaluation of the system.

White box testing: testing that assesses the effectiveness of software program logic.

Black box testing: an integrity-based form of testing associated with testing components of an
information system's "functional" operating effectiveness without regard to any specific internal program
structure.
 3.5.2 TESTING CLASSIFICATIONS
Function/validation testing: used to test the functionality of the system against the detailed
requirements to ensure that the software that has been built is traceable to customer requirements.

Regression testing: the process of rerunning a portion of a test scenario or test plan to ensure that
changes or corrections have not introduced new errors.

Parallel testing: the process of feeding test data into two systems - modified system and
alternative/original system - and comparing the results.

Sociability testing: tests to confirm that the new or modified system can operate in its target
environment without adversely impacting existing systems.
3.5.2 SOFTWARE TESTING

Test Approaches:
1. Bottom Up: A testing strategy that begins testing of atomic units, such as programs or
modules, and work upward until a complete system testing has taken place.

2. Top Down: A testing strategy where the component at the top of the component hierarchy
is tested first, with lower level components being simulated by stubs; tested components are
then used to test lower level components; the process is repeated until the lowest level
components have been tested.
3.5.3 DATA INTEGRITY TESTING

Set of substantive tests that examines accuracy, completeness, consistency and authorization of
data presently held in a system.

Testing types:

 Relational Integrity Tests

 Referential Integrity Tests
3.5.4 APPLICATION SYSTEMS TESTING

Testing the effectiveness of application controls involves analyzing computer application

programs, testing computer application program controls, or selecting and monitoring data
process transactions

Generalized audit SW (GAS) can be used to perform certain application control tests
 3.6. DATA MIGRATION AND CONVERSION

Data migration: The moving of data from the original application system into the
newly implemented system.

Data conversion: The conversion of existing data into the new required format,
coding schema and file/database structure while preserving the meaning and
integrity of the data.
3.6.1 CHANGEOVER TECHNIQUES
Changeover
Refers to an approach to shift users from using the application from the existing (old) system to
the replacing (new) system. This can be achieved in 3 ways/approaches :
1. Parallel changeover: running the old system, then running both the old and new systems in
parallel, and finally fully changing over to the new system after gaining confidence in the
working of the new system.

2. Phased changeover: where the older system is broken into deliverable modules; the first
module of the older system is phased out using the first module of the new system, then the
second module is replaced, and so on until the last module is replaced.

3. Abrupt changeover: the newer system is changed over from the older system on a cutoff
date and time, and the older system is discontinued once the changeover to the new system
takes place.
3.6.2 SYSTEM IMPLEMENTATION
It is initiated only after a successful testing phase

IS auditor should perform the following:

 Review the programed procedures used for scheduling and running the system
 Review all system documentation to ensure its completeness
 Verify all data conversions to ensure they are correct and complete
3.6.3 SYSTEM CHANGE PROCEDURES
 Following implementation, a system enters into the ongoing development or maintenance
stage.

 This phase continuous until the system is retired

 This involves activities required to either correct errors in the system or enhance the capability
of the system
3.6.3 SYSTEM CHANGE
PROCEDURES
IS Auditor’s Role in Change Management:

The IS auditor should review the change management process for possible improvements in the
following:
 Response time
 response effectiveness
 User satisfaction with process
 3.6.3 SYSTEM CHANGE
PROCEDURES
Critical Success Factors of planning the implementation
 To avoid delays, the appropriate skilled staff must attend workshops and participate for the
entire project duration.

 The documentation needed for carrying out the work needs to be ready at project initiation.

 Decision makers must be involved at all steps to ensure all necessary decisions can be made
quickly.
 3.6.3 SYSTEM CHANGE
PROCEDURES
End User Training:
To ensure that end user can become self-sufficient in the operation of the system
One of the most important keys in end-user training is to ensure that training is considered and a training project plan is
created early in the development process
To develop the training strategy, an organization must name a training administrator who will identify users who need to
be trained with respect to their specific job functions
 Consideration should be given to the following format and delivery mechanisms:

 Case Studies

 Role based training

 Lecture and breakout sessions

 Modules at different experience levels

 Practical sessions on how to use the system

 Online Sessions on the web

 3.7. POST-IMPLEMENTATION REVIEW
Post-implementation review include the following:

Adequacy of the system

 Does the system meet user requirements and business objectives?

 Have controls been adequately defined and implemented?

ROI measurement

Recommendations that address any system inadequacies and deficiencies

Plan for implementing recommendations

Assessment of project process

 Were chosen methodologies, standards, and techniques followed?

 Were appropriate project management techniques used?

 3.7.1 IS AUDITOR’S ROLE IN POST-
IMPLEMENTATION REVIEW
 Determine if the system’s objectives and requirements were achieved

 Determine if the cost benefits identified in the feasibility study are being measured, analyzed

and accurately reported to management

 Review program change requests performed to assess the type of changes required of the system

 Review controls built into the system to ensure they are operating according to design

 Review errors’ logs to determine if there are any resources or operating problems inherent within

the system