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)
 3.4.1. INPUT/ORIGINATING
CONTROLS
Input control techniques include:
▪ 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