CISA - Domain 3 - IS Acquisition, Development and Implementation

Certified Information System Auditor (CISA®)
Domain 03: IS Acquisition, Development, and Implementation
An ISACA® Certification based on CISA® 2014 Curriculum.

Copyright 2014, Simplilearn, All rights reserved.
Copyright 2012-2014, Simplilearn, All rights reserved.
Objectives
After completing ● Understand and provide assurance that the practices for the acquisition,
this domain, you
development, testing and implementation of information systems meet
will be able to:
enterprise strategies and objectives
● Discuss project management control frameworks
● Detail configuration and release management
● Understand system migration and infrastructure deployment practices
● List project success criteria and risks
● Understand post-implementation review objectives and practices
2 Copyright 2012-2014, Simplilearn, All rights reserved.

Overview
Organizations need proper processes and methodologies to create and change application
systems and infrastructure components. This is called information systems lifecycle management.
Information systems lifecycle management requires thinking from end-to-end, encompassing:
● planning acquisition,
● acquisition,
● use, including maintenance, and
● retiring of,
information systems.
The CISA candidate must understand the various concepts and be able to identify which elements
may represent the greatest risk and which controls are the most effective at mitigating this risk.

IS Acquisition, Development, and Implementation
Knowledge Statement 3.1

Benefits Realization Practices
Knowledge of benefits realization practices (e.g. feasibility studies, business cases, TCO, ROI)
Explanation:
● The objective of IT projects is to realize tangible benefits.
● Managing these benefits is essential to the success of projects.
● A cost benefit analysis should be prepared prior to beginning a project.
● This should estimate all costs and benefits throughout the life of a new system.
! The IS Auditor should ensure that when a cost benefit analysis is being prepared for a project under consideration, the
risks associated with the project have been assessed and the cost factor includes the cost of necessary controls.

Main Areas of Coverage
The main areas covered under this knowledge statement include:

● Business Realization
● Business Case Development and Approval
● Benefits Realization Techniques
● Description of Traditional SDLC Phases
● Feasibility Study

Benefits Realization
Benefits realization is the process by which an organization evaluates technology solutions to business
problems. Factors in benefits realization include:
● cost;
● quality;
● development/time delivery;
● reliability; and
● dependability.

Benefits Realization Technique
In the Benefits Realization Technique, also called Benefits Management, the organization considers
total benefits and total costs throughout the life of the new system.
The post-implementation review, involving documentation of lessons learnt, can be done between six
to eighteen months after implementation of the system.
This review must be part of governance and management of projects.

Business Case Development and Realization
A business case is normally derived from the feasibility study, and contains information for the
decision-making process on whether a project should be undertaken.
A feasibility study scopes the problem, outlines possible solutions, and makes a recommendation on
what action to take. A business case of sufficient detail for each solution should be developed in order
to allow a comparison of costs and business benefits.

Business Case Requirements
A business case should:
● answer the question, “Why should this project be undertaken?”
● be a key element of the decision process throughout the life cycle of any project.
● be reviewed to ensure that it is still valid.
● be reapproved through departmental planning and approval process, if the business case changes
during the project.

SDLC—Feasibility Study
A feasibility study in business case development:

● scopes the problem;
● outlines possible solutions; and
● makes a recommendation on what action to take regarding the undertaking of a project.
The feasibility study defines:
● the need or problem and possible or alternative solutions to the need;
● Financial appraisal which can use different techniques such estimated payback period and return
on investment (ROI) , Internal Rate of Return (IRR), among others;
● expected benefits such as productivity gains, cost reduction; and
● intangible benefits.

SDLC—Feasibility Study (contd.)
A feasibility study involves an assessment of:

● risks associated with the solutions;
● buy versus develop;
● timeframe required to implement the solution;
● whether the current system can be modified to meet the need;
● availability of vendors for the solutions identified; and
● compatibility with the business strategy.
The key output of feasibility study is a comparative report, with all alternatives analyzed and the
recommended alternative or solution.

Traditional SDLC Phases—Waterfall Model
Traditional SDLC or the waterfall model is based on a systematic, sequential approach to software
development (largely of business applications). It is the oldest and most widely used methodology for
developing systems.
SDLC phases are as follows:
● Feasibility study – defining the problem and developing the business case justification
● Requirements definition — defining the functional and quality requirements of the desired
solution.
● Design – developing baseline system specifications including security plans
● Development – of programming and testing
● Implementation – of deploying the new system, user acceptance testing, and commissioning

Disadvantages of Traditional SDLC
Disadvantages of Traditional SDLC Phases are listed here:

● It is unrealistic, as unanticipated events typical in real programs rarely follow a structured
sequence.
● Changing business environment alters user requirements before final delivery and managing
requirements becomes essential to ensure functionality is not compromised.
● User requirements are rarely captured fully at the early stages as required.
● Working version of the system is only available towards the end, necessitating user patience.
The only advantage of traditional SDLC is that it provides a template for capturing requirements.

SDLC—Design
Design involves developing blueprints of the system and its components :

● Blueprints should show how requirements will be met.
● Design may involve several iterations to get to the level of detail required for development/coding.
Components or modules of design are as follows:

● system flowcharts, data and process flows,
● input and outputs, screen designs and reports,
● processing steps and computation rules,
● program specifications and database file design,
● test plans (unit, subsystem/module, integration/system, interfacing, security, backup and
recovery), and
● data conversion plans (analysts and programmers involved, users are not so much involved in this
stage).

SDLC—Design (contd.)
Software Baseline
● sets a cut-off point beyond which changes require strict formal approval;
● guards against scope creep; and
● introduces software configuration management.
Change control processes
● ensure new requirements or changes are subject to the same formal review and approval
procedures; and
● prevent uncontrolled entry of new requirements.

SDLC—Testing
SDLC testing ensures that:

● programs function as designed; and
● operate without malfunction or adverse affect on other system components.
General testing levels are:

● Unit testing:
o testing individual programs or modules
● Interface/integration testing:
o connection of two or more components that pass information

SDLC—Testing (contd.)
● System testing: collective constitution of the programs/modules as one system:

o Recovery testing is the ability to recover from failure;
o Security testing refers to access controls and impact on other systems;
o Load testing refers to testing performance during peak hours (processing with large volumes of data);
o Volume testing means applying incremental records to determine maximum volume of data the application can
process;
o Stress testing refers to concurrent users and/or services that can be supported at a time (by increasing
transactions progressively); and
o Performance testing i.e. comparing against other equivalent systems and/or benchmarks.
● Final acceptance testing done during implementation, and considers:

o Quality assurance (technical aspects): focuses on documented specifications and technology employed.
o User acceptance (functional aspects): assesses if the system production ready and satisfy all requirements

SDLC—Testing Terminology
Following are the terminology frequently used in software testing:

● Alpha and beta testing – testing before the program is finished
o alpha testing involves internal users only
o beta testing is the last stage of testing involving a small number of external users
● Pilot testing: preliminary test focusing on specific, predetermined aspects of the system;
● White box testing: close examination of procedural detail and specific logic paths;
● Black box testing:
o examination of outputs and observable system behavior;
o disregards internal program structure; and
o applicable to integration and user acceptance testing.

SDLC—Testing Terminology (contd.)
● Function/validation testing: testing functionality against detailed requirements;
● Regression testing: rerunning tests to ensure changes or corrections have not introduced errors
data used should be the same as data used in original system;
● Parallel testing: feeding test data into two systems and comparing results;
● Sociability testing: evaluating impact on existing systems or environment; and
● Automated application testing:
o test data generators are used to systematically generate random test data;
o interactive debugging aids and code logic analyzers are available to assist in testing activities.

SDLC—Implementation
The SDLC implementation phase involves the following activities:
● The new system is put into operation, and involves final acceptance testing.
● Certification: Meeting minimum security requirements as set by the organization. An assessor

organization can be tasked to do this.
● Accreditation: A senior official in management takes up responsibility and accountability of using

the system in operations and the resultant impact.
● Certification and accreditation ensures effectiveness at:

o mitigating risks to an appropriate level and establishing level of internal control; and
o provide management accountability on systems effectiveness in meeting intended business objectives.

SDLC—Implementation (contd.)
● The final step in implementation is migration to production/live environment, during which:
o testing is completed;
o procedures are documented and in place;
o necessary data is converted into the new system; and
o user training is completed.

SDLC—Implementation Plan
An implementation plan indicates:

● the staff responsible as the single point of contact (SPOC);
● the tasks and the process of verifying the tasks;
● the timetable; and
● back-out procedures to handle any problems encountered.
The phases in implementation are as follows:
Phase 1: Develop to-be support structures Phase 2: Establish support functions

● Gap analysis ● SLA
● Role Definition ● Implementation plan/knowledge transfer plan
● Training plans

SDLC—Implementation Plan (contd.)
Data Migration/Porting:
● what data to convert programmatically and what to convert manually;
● any necessary data cleansing;
● methods to verify conversion, For example; file comparisons, balance comparisons;
● parameters for successful conversion, e.g. percentage consistency;
● scheduling and sequencing of conversion tasks;
● documentation of audit trails e.g. data mapping;
● exception reports to capture items not converted automatically;
● responsibility for verifying and signing off conversion steps;
● testing conversion programs; and Carry out conversion “dress rehearsals”.
● Control of outsourcing conversion process ensuring nondisclosure, data privacy/destruction and
other
SDLC— Data Migration
Proper processes and building tools should be required to extract data from legacy system to
target system


Benefits Realization Practices

Knowledge of project governance mechanisms (e.g., steering committee, project oversight
board, project management office)
Explanation:
● Strong project governance is essential for successful project implementation.
● Effective and efficient deployment of project resources is enhanced by having adequate project
governance mechanisms.
● The more complex the project, the more elaborate the governance structures and mechanisms.
The IS Auditor should be aware of the available business structures that should support and manage a project and the
! essential constituents of these structures, i.e., who should lead the various committees, who should be members, roles
and responsibilities, etc.


● Portfolio/Program Management
● Project Management Structure
● Project Organization Forms
● Roles and Responsibilities of Groups and Individuals

Project Management Structure
Project Management Structure:

● This is the approach to project management.
● There are many approaches for project management. They are either focused on software
development or a more general approach.
Different approaches used are:
● Project Management Body of Knowledge (PMBOK®) - (IEEE Standard 1490) from PMI Institute;
● Projects In Controlled Environment (PRINCE2®) from the office of Government Commerce (OGC) in
the UK; and
● International Project Management Association (IPMA).

IS Project Management
General aspects of project management approaches:

● IS project may be initiated from any part (division, department or function) of the organization.
● Projects are time bound, that is, they have start and finish dates.
● Risk element exists in every project.
● A project has specific deliverables and objectives.
● The project management process should be well designed. For instance, a business process
reengineering (BPR) project requires extensive planning to succeed.

Program
A program is a group of projects and time-bound task that are closely linked together through:
● common objectives,
● a common budget, and
● intertwined schedules and strategies.
Like projects, programs have a limited time frame (start and end date) and organizational boundaries.

Program vs. Project
Following are the point of differences between Program and Project:

● Programs are more complex, usually have a longer duration, a higher budget, and higher risks
associated with them and are of higher strategic importance than projects.
● Projects are much smaller in scale in terms of the attributes mentioned in the above bullet point.
● A program can constitute many projects.

Portfolio and Program Management
Portfolio and Program Management is the application of knowledge, skills, tools and techniques
towards a stated objective.
Example: Business Process Reengineering (BPR) or process automation undertaking in an organization

can be thought of as a program by virtue of having the characteristics mentioned in the previous slide.
It may involve the following projects:
● Network Infrastructure Upgrade (e.g. creating a wide area network (WAN) to link branches in
different countries, states or cities)
● Business Application Development project such as Payroll, Financial Management System,

Customer Relationship Management (CRM) system
● Training of staff to understand the new processes and change in their roles
Portfolio and Program Management (contd.)
Portfolio or Program management basically involves controlling time and resources: It:
● consists of initiating, planning, executing, controlling and closing a Program;
● covers software size estimation, scheduling, allocating resources and measuring productivity.

Project Roles
The following diagram shows the different organizational stakeholders involved in a project.
Senior Management
Project Sponsor
Steering Committee
User Management
Quality Assurance
Project Manager
Systems
Technical
Development User Project Team Security Officer
Infrastructure Team
Project Team

Roles and Responsibilities
Responsibilities of the different roles are as follows:

● Senior management – commitment and final approval
● User management – Program and system owner who assigns resources, approves deliverables, and
participates in requirements definition, acceptance testing and user training
● Program steering committee – provides overall direction, appropriately represents all affected
parties, and ultimately responsible for costs and timetable
● Program sponsor – funds the Program, is typically the senior manager of the affected business
function, and chairs the Program Steering Committee
● Program manager – day-to-day program management

Roles and Responsibilities (contd.)
Responsibilities of some other roles are as follows:

● System development management – provides technical support for hardware and software
environment
● Systems development program team – technical staff who perform Program tasks
● User program team – users who perform program tasks
● Security officer – ensures adequacy of system controls and compliance to security policies
● Quality assurance – reviews deliverables for compliance to requirements and defined standards
● IS auditor – ensures controls are implemented in the new system


Project Management Control Frameworks, Practices and Tools
Knowledge of project management control frameworks, practices and tools
Explanation:
● The project manager’s skill set should be commensurate with the project at hand.
● To manage all the relevant parameters of a large project, project management practices, tools and
control frameworks are required.
● Projects need to be managed on hard, soft, and environmental factors
The IS Auditor should be aware of the available business structures that should support and manage a project and the
! essential constituents of these structures, i.e., who should lead the various committees, who should be members, roles
and responsibilities, etc.


● Project Objectives
● Initiation of a Project
● Project Planning
● Project Controlling
● Closing a Project
● Description of Traditional SLDC phases
● Development Methods
● Use of Structured Analysis, Design and Development Techniques
● Infrastructure Development
● Process Improvement Practices
● Business Process Reengineering and Process Change Projects.
● ISO 9126
● Capability Maturity Model Integration

Project Organizational Forms
Following are the project organizational forms:

● Influence – Project Manager (PM) has no formal authority, only has a staff function and only has
an advisory role.
● Pure project – Project Manager has formal authority, at times special working area provided from
normal office.
● Matrix project organization – management authority shared between project manager and
departmental heads.

Project Objectives
Project Objectives are as follows:

● Main objectives are those objectives that contribute to the success of the project such as faster
transaction time
● Additional objectives are objectives that are not directly related to the main results of the project
but may contribute to project success (e.g., business unit reorganization in a software
development project).
● Non-objectives add clarity to scope and make project boundaries become clearer
● These objectives can be defined using an Object Breakdown structure

Project Communication
On initiating a project management process, communication may be achieved in a number of ways

depending on its size and complexity as shown below. Project Communication types are as follows:
● One-on-one meetings – facilitate two-way communication between project team members and
the project manager.
● Kick off meetings – used by project manager to inform team of what of what has to be done for
the project
● Project start workshops – ensure communication is open and clear, allow buy-in from stakeholders

Project Culture
Project Culture represents the norms and rules of engagement of the project. It is the common
understanding or the orientation expected of the team.
Project culture development /influencing method includes:
● establishment of a project mission statement,
● project name and logo,
● project office or meeting place,
● project intranet,
● project team meeting rules and communication protocols, and
● project specific social events.

Project Management Practices and Project Initiation
Project Management practices refer to the application of knowledge, skills, tools and techniques to a
broad range of activities to achieve a stated objective such as meeting the defined user requirements,
budgets and deadlines for an IS project.
Project management processes include:
● Initiating;
● Planning;
● Executing;
● Controlling; and
● Closing the project.

Project Management Practices and Project Initiation (contd.)
Projects have three key intertwining elements called Deliverables, duration and budget (these should
have positive correlation).
The project is initiated by a project manager or a sponsor gathering all information required to gain
project approval in the Project Charter. The Project Charter or Terms of Reference contains:
● Objective of the project,
● Stakeholders of the expected, and
● Project manager and sponsor.
Approval of the Project Initiation Document (PID) or a Project Request Document (PRD) is
authorization of the project to begin

Software Size Estimation
Software Size Estimation methods are used to determine the relative physical size of the application
software to be developed. These methods:
● guide allocation of resources, and estimation of time and cost required in order to compare the
total effort required by the resources
● traditionally done with single-point estimations (i.e. based on a single parameter) such as Source
Lines of Code (SLOC)
● now done using multiple point estimation, a good example being the Function point analysis (FPA)

Software Size Estimation (contd.)
One of the methods of software size estimation is Function Point Analysis (FPA):
● FPA is an indirect measure of the size of an information system (software size) based on number
and complexity of inputs, outputs, files, external interfaces and queries.
● Complexity adjustments (i.e. rating factors) are used based on analysis of reliability, criticality,
complexity, reusability, changeability and portability, etc.

Software Cost Estimation
Software Cost estimation is a consequence of software size estimation and involves estimation of
programs at each phase. Automated techniques for cost estimation of projects can be used at each
phase of system development. Some of the components to consider when using these techniques
include:
● source code language
● execution time constraints
● main and data storage constraints
● computer access and target machine used for development
● security environment
● staff experience

Budgets and Schedules
Scheduling involves establishing the sequential relationships among tasks: logically, with allowance
for parallel tasks, while taking into account allocation of resources.
Budgeting involves estimating the amount of effort required in human hours and machine hours.
The schedule can be graphically represented using various techniques such as Gantt charts, Critical
Path Method (CPM), Program Evaluation Review Technique (PERT) diagrams. These tools should be
revisited to verify compliance and identify variances. Variances and variance analysis including cause
and corrective action should be reported to management on a timely basis.

Critical Path Methodology (CPM)
In the Critical path methodology (CPM) a project can be represented as a network where activities are
shown as branches connected at nodes immediately preceding and immediately following activities.
! Any delay on the critical path will translate to a delay in the whole project.

Program Evaluation Review Technique (PERT)
Program evaluation review technique (PERT) is used for planning and control, estimation of time and
resources required, and detailed scheduling (timing and sequence).

Gantt Charts
Gantt charts are a graphical representation of scheduled tasks.

Timebox Management
Timebox management is a project management technique for defining and deploying software
deliverables within a relatively short and fixed period of time, and with predetermined specific
resources. Timebox management:
● involves balancing software quality and meet the delivery requirements within the timebox or
time window.
● is well suited for prototyping or rapid application development.
● is aimed at preventing cost overruns and schedule delays (the main advantage of this technique)
● may result in quality being compromised for time.
● may include interfaces for future integrations in key features

Project Controlling Activities
The controlling activities of a project includes management of scope, resource usage and risk. New
requirements should be documented and, if approved, allocated the appropriate resources.
To manage scope, the deliverables breakdown is accompanied by proper documentation in a

component management database (CMDB).
Changes to scope will always lead to changes in activities hence impacting deadline and budget and
therefore need to be handled formally in a Change Management Process.

Project Controlling (contd.)
The steps in the Change Management Process are as follows:
1 2 3 4 5
The process Change request The Change If accepted the The project
starts with a is submitted to Advisory Board project manager sponsor after
formal change the project then evaluates updates the evaluating the
request manager (copies the change project plan to new plan may
containing a stored in project request (on reflect the accept or reject
clear description file) behalf of the requested the
of the requested sponsor) and change recommendatio
change and decides whether ns of the Change
reasons for to recommend advisory board
change the change

Resource Usage Management
Resource usage is the process by which the project budget is being spent.
● It checks if actual spending is in line with planned spending, resource usage must be measured and
reported.
● Every budget and project plan presupposes a certain "productivity" of resources and delivers the
expected quality of the outcome/deliverable.
● Earned Value Analysis (EVA) technique can be used to check this. It involves comparing the
following continuously:
o budget to date
o actual spending to date
For an example on Resource Usage Management, please refer to the e-learning material.

Risk Management
Risks are the possible negative events or conditions that would disrupt relevant aspects of the
project.
There are two main categories of project risk:
● Those that impact the project itself. The project manager is responsible for mitigating this risk
(risks within the project).
● Those that impact the business benefits and therefore endanger the reasons for the project's very
existence. The project sponsor is responsible for mitigating this risk (business risk of the project).

Risk Management Process Steps
Risk management process steps are as follows:

● Identify risks,
● Assess and evaluate risks,
● Manage risks,
● Monitor risks, and
● Review and evaluate risk management process.

Closing a Project
A project should be finite and at some point be closed with the new or modified system handed over
to the users and/or system support staff.
● The project sponsor should be satisfied that the system produced is acceptable and ready for
delivery.
● Custody of contracts may need to be assigned, and documentation archived or passed on to those
who will need it.
● Survey the project team, development team, users and other stakeholders to identify any lessons
learned that can be applied to future projects

Closing a Project – Post Project Review
Another important activity in closing a project is the post-project review.
In this, lessons learned and an assessment of project management processes used are documented.
These are referenced in the future by other project managers or users working on projects of similar
size and scope.
Project management practice descriptions and related concepts and theories behind best practices
! have been brought together in "body of knowledge" reference libraries (BoKs). Certification schemes
have subsequently been based upon such BoKs.
To learn about Process Improvement Practices, please refer to the e-learning material.

Business Process Reengineering
“It is a set of interrelated work activities characterized by specific inputs and value-added tasks that
produce specific customer focused outputs. Business processes consist of horizontal work flows that
cut across several departments or functions."
-(Seth, Vikram; William King; Organizational Transformation through
Business Process Reengineering, Prentice Hall, USA, 1998)
Business Process Reengineering (BPR):
● is a response to competitive and economic pressures, and customer demands,
● involves automating processes to reduce manual intervention and manual controls,
● needs to suit business requirements for benefits to be realized.

Business Process Reengineering (contd.)
Some notable successes of BPR are:

● Cost savings;
● Streamlining of operations;
● Advantages of centralization; and
● Changes in business conduct.
BPR steps are as follows:
● Define the areas to be reviewed and develop a Program plan,
● Understand the process under review and re-design and streamline the process, and
● Implement and monitor the new process and establish a continuous improvement process.
To learn about ISO 9126, please refer to the e-learning material.

Software Capability Maturity Model
The Capability Maturity Model (CMM) for Software is a process maturity model or framework that
helps organizations improve their software lifecycle processes. CMM helps organisations by:
● Improving their software life-cycle processes; and
● Preventing excessive Program schedule delays and cost overruns.
● Guiding software organisations in selecting process improvement strategies by determining
current process maturity, and identifying most critical issues to quality and improvement.
● Defining five maturity levels: Initial; Optimised, Repeatable, Defined;

Capability Maturity Model Integration
Capability Maturity Model Integration (CMMI) was conceived as a means of combining the various
models into an integrated set. CMMI also describes five levels of maturity, although the descriptions
of what constitutes each level differ from those used in the original CMM.
! ISO 15504 is also known as SPICE (Software Process Improvement and Capability Determination). It is
based on CMM and is similar to CMMI.


Risk Management Practices
Knowledge of risk management practices applied to projects
Explanation:
● Proper risk management is required in order to minimize the consequences and the likelihood that
the project fails to achieve its goals.
● Major issues include: scope/deliverables, quality, budget and time.
● Risk management is a continuous process, not a one-time activity, since risk profiles will change
over time.
Main Area of Coverage: Risk Associated with Software Development
! As a “controls expert”, the IS Auditor will be expected to ensure that business risk is considered by the project during all
phases of development.

Risks Associated with Software Development
Risks associated with software development are as follows:

● Business risk or benefit risk: the likelihood that the new
system may not meet the users' business needs,
requirements and expectations.
● Project risk or delivery risk: where 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.

Levels of Software Project Risk
Software project risks exists at the following levels:

● Within the project – risks associated with not identifying the right requirements to deal with the
business problem or opportunity that the system is meant to address
● With suppliers – failure to clearly communicate requirements and expectations, resulting in
suppliers delivering late, over the expected cost and/or with deficient quality
● Within the organization – stakeholders not providing needed inputs or committing resources to
the project
● With the external environment – impacts on the projects caused by the actions and changing
preferences of customers
● With the chosen technology (technology risk) – sudden displacement of technology by a more cost
efficient one

IT Architecture Related to Data, Applications and Technology

Knowledge of IT architecture related to data, applications and technology (e.g., distributed
applications, web-based applications, web services, n-tier applications)
Explanation:
● Enterprise Architectures describe an organization’s structure, including business processes,
information systems, human resources and organizational units.
● Enterprise Architectures are supported or served by IT Architectures e.g., n-tier, client-server, web-
based and distributed components.
Main Area of Coverage: Components of enterprise architecture
! The IS Auditor must understand the role of these components and how control objectives are met across all
components to determine whether risk is sufficiently mitigated by these controls.
To learn about Business Application Systems, please refer to the e-learning material.
Electronic Commerce (E—commerce)
E-Commerce refers to buying and selling online, usually via the internet, using technology to enhance
the processes of commercial transactions.
E-Commerce models include:
● business-to-customer (B-to-C);
● business-to-business (B-to-B);
● business-to-employee (B-to-E);
● business-to-government (B-to-G);
● customer-to-government (C-to-E); and
● exchange-to-exchange (X-to-X).

Electronic Commerce Architecture
Electronic Commerce Architecture can be described as follows:

● 2-tier, client browser and web-server;
● 3-tier, client browser, web-server and database server;
● Integrate web channel with a business’ internal legacy systems and systems of its business
partners.
● component-based systems that use middleware around an application server (to meet the
challenge of diverse technologies); and
● Systems relying on multiple computer platforms- “n-tiered” e.g. client browser, web server (handle
web content), Application server (business logic) and database (data storage).

Electronic Commerce Architecture (contd.)
Application server provide services such as data management, security & transaction management.
XML (extensible mark-up language):

● Facilitates electronic publishing;
● Allows storing of any kind of structured information.

Electronic Commerce Risks
Electronic Commerce risks can be categorized as follows:

● Confidentiality – Providing unknown vendors with personal information (e.g. credit card on
purchase) which can be stolen.
● Integrity – Data in transit and in storage exposed to unauthorized alteration or deletion (hacking e-
business system).
● Availability – 24/7 requirement - failure highly noticeable - leading to loss of business.
● Authentication and nonrepudiation – Requires a trusted business relationship - to avoid man-in-
the-middle attacks.
● Power shift to customers – Ease of shift between suppliers, requires reengineering of business
processes.

Electronic Commerce Risks (contd.)
Following are the requirements of E-commerce:

● A business case (IT as an enabler) around the 4 Cs: customers, costs, competitors and capabilities,
● A clear business purpose,
● Improved costs through technology,
● Top-level commitment,
● Business process re-configuration, and
● Links to legacy systems, typically through middleware.

The major risk is transaction authorization i.e. matters of legal liability between partners may be put
in a trading partner agreement.
Other Risks of E-commerce include:
● Loss of business continuity;
● Unauthorized access to electronic transactions;
● matters of legal liability between partners may be put in a trading partner agreement;
● deletion or manipulation of transactions prior to or after establishment of application controls;
● loss or duplication of EDI transmissions; and
● improper distribution of EDI transactions while in the possession of third parties.

Key controls of e-commerce include the following:
● Virus protection
● Continuity planning
● Continuous review/audit of controls
● Digital Signatures
● Firewalls mechanisms
● Public key infrastructure: CA, RA, CRL, CPS
● Recognition of breaches–IDS

Other key controls of e-commerce include the following:

● Security mechanisms and procedures that provide security architecture for ecommerce (e.g.
firewall, PKI, encryption, certificates and password management)
● Process of identification of participants in ecommerce applications
● Procedures for change management in ecommerce presence
● Detection controls: system logs and intrusion detection systems

Electronic Data Interchange (EDI)
EDI is an electronic means for transmitting business documents between organizations in a standard
machine recognizable format. It is used to transmit business transactions between organizations with
dissimilar computer systems.
Benefits of EDI are:
● Less paperwork
● Fewer errors during information exchange
● Improved information flow
● No unnecessary re-key of data
● Fewer delays in communication
● Improved invoicing and payment processes

EDI Requirements and Approaches
General requirements for EDI are as follows:
● system software: communication / transmission, translation, and storage;
● application software that performs business activities; and
● access to standards: document standards and partner profiles.
Approaches to EDI can be:
● Traditional, or
● web-based.

EDI Process
Moving data in a batch transmission process through the traditional EDI involves three functions
within each trading partner’s computer system:
● Communications handler that transmits and receives electronic documents between trading
partners
● EDI interface manipulates and routes data between the application system and the
communications handler
o EDI translator: Translates data between the standard ANSI format and a trader’s proprietary format.
o Application interface: Moves electronic transactions to and from application systems, and performs data
mapping.
● Application system processes the data to be sent to or received from the trading partner


IT Acquisition Practices

Knowledge of IT acquisition practices (e.g., evaluation of vendors, vendor
management, escrow)
Explanation:
● Use of vendors can speed a project and potentially reduce total costs.
● However, use of vendors add risks, especially if the vendor is single or sole-source provider .
● Proper vendor management can reduce/ prevent problems caused by picking a vendor that is
unable to achieve the required solution or timescale and by ensuring that contracts address
business needs and do not expose the business to unnecessary risk.


● Infrastructure Development/Acquisition Practices
● Hardware Acquisition
● System Software Acquisition
The IS Auditor must understand: the importance of requirements specification that forms the request for proposal
(RFP); the need for required security and other controls to be specified, the essential elements of vendor selection to
! ensure that a reliable and professional vendor is chosen and the essential contents of the contract – most notably,
the need, as appropriate, for an escrow agreement to be in place. The right to audit must also be addressed in the
contract.

Hardware Acquisition
Selection of a computer hardware and software environment frequently requires the preparation of
specifications for distribution to hardware/software (HW/SW) vendors and criteria for evaluating
vendor proposals.
The specifications are sometimes presented to vendors in the form of an invitation to tender (ITT),
also known as a request for proposal (RFP).

Hardware Acquisition (contd.)
When acquiring a system, the specifications should include the following:

● Organizational descriptions indicating whether the computer facilities are
o centralized or decentralized,
o distributed,
o outsourced,
o manned or lights-out.
● Information processing requirements
● Hardware requirements
● System software applications
● Support requirements
● Adaptability requirements
● Constraints
● Conversion requirements

When purchasing (acquiring) hardware and software from a vendor, consideration should be given to
the following:
● Testimonials or visits with other users
● Provisions for competitive bidding
● Analysis of bids against requirements
● Comparison of bids against each other using predefined evaluation criteria
● Analysis of the vendor's financial condition
● Analysis of the vendor's capability to provide maintenance and support (including training)
● Review of delivery schedules against requirements

Other considerations include:

● Analysis of hardware and software upgrade capability
● Analysis of security and control facilities
● Evaluation of performance against requirements
● Review and negotiation of price
● Review of contract terms (including right to audit clauses)
● Preparation of a formal written report summarizing the analysis for each of the alternatives and
justifying the selection based on benefits and cost

System Software Acquisition
When selecting new system software, the business and technical issues considered include:
● Business, functional and technical needs and specifications
● Cost and benefits
● Compatibility with existing systems
● Security
● Demands of existing staff
● Training and hiring requirements
● Future growth needs
● Impact on system and network performance
● Open source code vs. proprietary code

Infrastructure Development/Acquisition Practices
Challenges to ICT Infrastructure development and acquisition include the following:

● Alignment with corporate standards
● Security
● Integration with existing systems
● IT industry trends
● Scalability and flexibility
● Maintainability (cost effective)
● Standardized hardware and software
● ROI, cost and operational efficiency

Infrastructure Development/ Acquisition Practices (contd.)
Phases in ICT Infrastructure Development and Acquisition are as follows:

● Review of existing architecture
● Analysis and design
● Functional requirements
● Proof of concept
● Procurement
● Implementation planning
● Delivery
● Installation

Request for Proposal Process
The requirements for an RFP are given in the following table:
Items Description
Product vs. systems The chosen vendor product should come as close as possible to meeting the
requirements defined requirements of the system.
Customer references Project management should check vendor-supplied references to validate the
vendor’s claims of product performance and completion of work done by the
vendor
Vendor The vendor should be reputable and should be able to provide evidence for
viability/financial financial stability.
viability
Availability of complete The vendor should provide a complete set of system documentation for review
and reliable prior to acquisition.
documentation

Request for Proposal Process
Items Description
Vendor support The vendor should make available a complete line of support products for the software.
Source code availability If not received from the vendor initially, there should be provisions for acquiring the source
code in the event that the vendor goes out of business. To avoid this risk, the clauses should
be part of the proprietary agreement in which a third party holds the software in escrow
should such an event occur . This escrow agreement should include product updates and
program fixes.
Number of years More years indicate stability and familiarity with the business the product supports.
experience
in offering the product
Number of clients sites A larger number suggests wide acceptance of the product in the market place.
using the product with a
list of current users.
Acceptance testing of the This is important in ensuring that the product really satisfies your
product system requirements. This is allowed before a purchasing
commitment must be made.


Requirements Analysis and Management Practices

Knowledge of requirements analysis and management practices (e.g., requirements verification,
traceability, gap analysis, vulnerability management, security requirements)
Explanation:
● Tracking and monitoring requirements ensure that project resources are focused on the correct
tasks.
● Requirements gathering is one of the most critical and difficult activities of the development life
cycle.
● Requirements should be prudent; feasible; cost-effective; and above all, aligned with business
strategy, plans and policies.
● Requirements should be documented to facilitate the understanding of the developers and
formally approved and frozen (baselined) to prevent scope creep.
Main Area of Coverage: Requirements Analysis in SDLC

Requirements Analysis in SDLC
Requirements Analysis involves identifying and specifying requirements of the system chosen
Decisions on Requirement Analysis are made on:
● system processes;
● user requirements and interaction;
● information criteria (effectiveness, efficiency, confidentiality, integrity, availability,compliance,
reliability); and
● system operating environment (that is, operating system).

Requirements Analysis in SDLC (contd.)
Requirements analysis in SDLC involves:
● determining stakeholders’ expectations;
● conflict resolution and prioritisation of issues;
● defining system boundaries and interaction with the environment;
● iteratively translating user requirements into system requirements;
● structured documentation of requirements; and
● conflict resolution with regards to resource allocation.

Requirements Analysis in SDLC (contd.)
User involvement is critical:

● For nominating representatives from affected user departments;
● To obtain commitment; and
● To ensure full benefit from the system.
An important tool for creation of a general preliminary design is an Entity Relationship Diagram (ERD).

Key Outputs of Requirements Analysis
Key outputs include:

● Preliminary system design that:
o is presented to user management for approval and endorsement; and
o prevents using resources on developing a system that does not meet requirements.
● Program schedule, which helps secure:
o commitments from systems developers; and
o necessary resources from affected departments.
IS auditors look out for:
● user involvement; and
● consideration of security requirements, audit trails.
To learn about the Entity Relationship Diagram (ERD), please refer to the e-learning material.


Project Success Criteria and Risks

Knowledge of IT architecture related to data, applications and technology (e.g., distributed
applications, web-based applications, web services, n-tier applications)
Explanation:
● Each project has unique success criteria based on the expectations of its stakeholders.
● The project sponsor is a key stakeholder who defines such success criteria.
● One technique to describe success criteria and deliverables is called the object breakdown
structure.
● Success criteria allow the project manager to focus on those risks that are most important for the
successful completion of the project.
Main Areas of Coverage: V-model, Object Breakdown Structure

V-model
The verification and validation model or V-model, also

emphasizes the relationship between development phases
Requiremen Acceptance
and testing levels. ts modelling Testing
● A risk in any software development project is that the final Architectura System
l Design Testing
outcome may not meet all requirements.
Component Integration
Design Testing
● The V-model approach ensures that potential mistakes are
corrected early and not solely during final acceptance Code
Unit Testing
Generation
testing.
Executable software
To learn about Object Breakdown Structure (OBS), please refer to the e-learning material.

Control Objectives and Techniques

Knowledge of control objectives and techniques that ensure completeness, accuracy, validity and
authorization of transactions and data
Explanation:
● Poor controls over data input, processing, storage or output increase the risk of loss to an
enterprise.
Main Area of Coverage:
● Input/Origination Controls
● Processing Procedures and Controls
● Output Controls
The IS Auditor must be aware of the need for controls to ensure the authorization, accuracy and completeness of data
! input to, processing by and output from computer applications. He/she must also know what types of control
techniques are available at each level and how each may be evidenced in the form of reports, logs and audit trails.

Processing Procedures and Controls
Following are the examples of processing procedures and controls:

● Manual recalculations
● Editing, to test accuracy, completeness and validity
● Run-to-run totals, to verify data through stages of processing
● Programmed/automated controls, to detect errors and initiate corrective action
● Reasonableness verification of calculated amounts
● Limit checks on calculated amounts
● Reconciliation of file totals
● Exception reports

Data Validation and Edit Controls
Following are the examples of data validation and edit controls:

● Sequence checks
● Limit checks
● Range checks
● Validity checks
● Reasonableness checks
● Table look-ups
● Existence checks
● Key verification
● Check digit
● Completeness checks
● Duplicate checks

Data Files Controls
Data Files Controls ensure that only authorized processing occurs to stored data. Categories of data
files and database tables are as follows:
● System control parameters
● Standing data
● Master/balance data
● File updating, maintenance authorization
● Before and after image reporting
● Maintenance error reporting and handling
● Source documentation retention

Data Files Controls (contd.)
Data file controls also include the following:

● Transaction files
● Internal and external labelling
● Correct version usage
● Data file security controls
● One-for-one checking
● Pre-recorded input
● Transaction log
● Parity checking

Output Controls
Output controls ensure that processed data is delivered to users in an consistent and secure manner.
They include the following:
● Logging and storage of negotiable, sensitive and critical forms in a secure place
● Computer generation of negotiable instruments, forms and signatures
● Output error handling
● Report distribution and control over print spools
● Balancing and reconciling


System Development Methodologies and Tools

Knowledge of system development methodologies and tools, including their strengths and
weaknesses (e.g., agile development practices, prototyping, rapid application development
[RAD], object-oriented design techniques).
Explanation:
● Organizations employ a methodology to reduce development time and improve maintainability of
the resulting code base.
● Controls appropriate to one form of development may not apply to other forms.
Main Area of Coverage: Alternate forms of Software Organization
! The IS Auditor must be aware of a variety of system development methodologies

in order to understand the applicable controls.

Alternate Forms of Software Project Organization
Alternate system development methodologies were developed to reduce development time,

maintenance costs, and to improve system quality. They include the following:
● Agile development
● Prototyping
● Rapid application development (RAD)
● Data-oriented system development
● Component-based development
● Web-based application development
● Re-engineering
● Reverse engineering
● Object-oriented system development

Agile and Heuristic Software Development
Agile development uses small time-boxed sub-programs/projects or iterations. After each iteration:
● the next iteration is planned; and
● the Program is re-evaluated: re-prioritizing and identifying new requirements.
There is greater reliance on people’s knowledge and small focused teams.
Heuristic or evolutionary development (prototyping) involves creating a system through controlled

trial-and-error. It takes SDLC into an iterative framework. Two approaches are:
● build a model to create the design; and/or
● gradually build the actual system.

Rapid Application Development (RAD)
RAD enables strategically important systems to be developed quickly while maintaining quality.
● It supports analysis, design, development and implementation of individual applications.
● It does not support planning/analysis of information needs of major business areas or the whole
organization.
RAD involves:
● small well-trained development teams;
● evolutionary prototypes;
● tools that support modelling, prototyping and component reusability;
● central repository;
● interactive requirements and design workshops; and
● rigid limits on time frames.
Development Methods – Object Oriented Systems Development
Object Oriented systems development contrasts from traditional approaches that treat data and
procedures separately. Data and procedures are grouped into an entity called an “object”:
Objects are organized into an aggregation hierarchy, with descriptions which show how services are
used. Object classes may inherit attributes and services from other object (parent) classes. Major
advantages of this method are as follows:
● Permits analysts, programmers, developers to consider larger logical chunks of a system
● Ability to manage unrestricted variety of data types
● Allows modelling of complex relationships

Alternate Development Methods – Component Based Development
Component Based Development involves assembling applications from co-operating packages of

executable software that avail services through defined interfaces. It is aimed at reducing
development effort by using as much pre-developed, pre-tested components as possible. The primary
benefit is the ability to buy proven, tested software from commercial developers.
Basic types of components are:
● In-process client components – must run from within a container e.g. Web-browser
● Stand-alone client components – expose services to other software, e.g. Excel
● Stand-alone server components – server processes that are initiated by remote procedure calls or
other network calls
● In-process server components – run on servers within containers

Alternate Development Methods – Web-based Applications
Web-based application development facilitates and standardizes code module and program
integration across platforms.
● Achieves easier and effective integration of modules within & between enterprises.
● It avoids the need for redundant computing tasks and redundant code; e.g. updating addresses
across different databases.

Alternate Development Methods – Reengineering
Re-engineering is updating an existing system by extracting and reusing design and program
components. Reverse engineering involves taking apart a system to see how it functions, and using
the information to develop similar systems. It involves:
● de-compiling executable code into source code, and
● using reverse-engineering tools to unveil functionality using black-box test data.

Alternate Development Methods – Data-Oriented System Development
Data-Oriented System Development involves representing software requirements by focusing on data

structure rather than data flow.
● It considers data independently from the processes that transform data.
● Data-oriented development compliments traditional development strategies.
● Examples: flight management systems and online stock exchange trading systems such as the NYSE


Testing Methodologies and Practices Related to ISs

Knowledge of testing methodologies and practices related to information systems development
Explanation:
● User Acceptance Testing (UAT) is undertaken to provide confidence that a system or system
component operates as intended, to provide a basis for evaluating implementation of
requirements, or to demonstrate the effectiveness/ efficiency of the system or component.
● Testing should be performed on a test system that closely matches the features of the production
system. Tests may be for individual components or interactions between various components or
the system as a whole.
Main Areas of Coverage: Test Application Systems and Data Integrity of Testing
! The IS Auditor should be familiar with QA concepts and methods and be able to test the compliance of the processes
and products with the methodology and standards adopted.

Testing Application Systems
Testing involves analyzing computer application programs, testing computer application controls, and
monitoring data process transactions.
Procedures for analyzing computer application programs include the following:

● Snapshot, to map program logic
● Mapping, to identify unused code
● Tracing and tagging, to trace a sequence of events

Testing Application Systems (contd.)
Procedures for testing computer application controls include the following:

● Using test data/deck – passing simulated transactions through live programs (or using auditor’s
data on client’s software)
● Base-case system evaluation – developing test data into comprehensive scenarios
● Parallel simulation: processing live data using simulated programs (or using auditor's software for
client's data)
● Parallel operation: processing data using old and new systems
Test data/deck and parallel simulation are common for testing in a batch processing environment.

Data Integrity Testing
Data integrity testing is testing the accuracy, completeness, consistency and authorization of data
held in systems. It indicate failures in input or processing controls. Types of data integrity is as follows:
● Relational integrity is enforced through data validation routines or input conditions and tests are
performed at data and record level.
● Referential integrity is ensuring that all references to a primary key from another file actually exist
in the original file.

Data Integrity Requirements
Data integrity requirements in online transaction processing systems (ACID):

● Atomicity – a transaction is either completed in entirety (all relevant database tables are updated)
or not at all
● Consistency – all integrity conditions in the database are maintained with each transaction
● Isolation – each transaction is isolated from other transactions
● Durability – changes to the database resulting from transactions reported as complete survive
subsequent hardware or software failures


Configuration and Release Management

Knowledge of configuration and release management relating to the development of
information systems
Explanation:
● Configuration and release management provide systematic, consistent and unambiguous control
on attributes of IT components comprising the system.
● Changes to IT systems must be carefully assessed, planned, tested, approved, documented and
communicated to minimize any undesirable consequences to the business processes.


● Information Systems Maintenance Practices
● Change Management Process Overview
● Configuration Management
! The IS Auditor should be aware of the tools available for managing configuration, change and release management and
of the controls in place to ensure segregation of duties between development staff and the production environment.

Change Management Process Overview
The change management process begins with authorizing changes which involves prioritizing and
approving change requests. This must involve:
● user and system staff;
● formal correspondence on change requests to system management; and
● a process of tracking status of requests, ensure requests are timely addressed.
Requests should be part of the systems permanent documentation.
Deploying changes with user acceptance tests; and user management approval to deploy.
Documentation facilitates future system maintenance.
● It should include system and user/operations documentation.
● Office copies for disaster recovery are also required

Change Management Process Overview (contd.)
Emergency changes are common when errors occur on system that are used in critical production job
processing. Procedures must ensure changes do not compromise system integrity.
Controls include:
● special logons for temporary programmer access;
● careful logging and monitoring of activities; and
● normal change controls applied retrospectively and documentation.

Configuration Management
Configuration management involves:
● maintenance requests formally documented;
● change control group approves maintenance;
● checkpoints, reviews and signoffs used at various stages of maintenance; and
● use of configuration management software.

Configuration Management (contd.)
As part of the software configuration management task, the maintainer performs the following task
steps:
● Develop the configuration management plan
● Baseline the code and associated documents
● Analyze and report on the results of configuration control
● Develop the reports that provide configuration status information
● Develop release procedures
● Perform configuration control activities such as identification and recording of the request
● Update the configuration status accounting database


System Development Methodologies and Tools

Knowledge of system migration and infrastructure deployment practices and data conversion
tools, techniques and procedures.
Explanation:
● Importing data form old (and legacy) systems into the new application is crucial.
● Data format, coding, structure and integrity are to be preserved or properly translated.
● A migration scenario must be set up, and a rollback plan needs to be in place.
● Source data must be correctly characterized, and the destination database must accommodate all
existing values.
● Resulting data should be carefully tested.
Main Area of Coverage: Computer-Aided Software Engineering

The IS Auditor should ensure that any tools and techniques selected for the process are adequate and appropriate, and
! that data conversion achieves the necessary objectives without data loss or corruption, and that any loss of data is both
minimal and formally accepted by user management.
Computer-Aided Software Engineering
Computer-aided software engineering (CASE) is the use of automated tools to aid in the software
development process. They aid in reducing effort in translating requirements and design information
into program logic for subsequent testing and implementation. Three categories of CASE are:
● Upper CASE: describe and document business requirements;
● Middle CASE: develop detailed designs; and
● Lower CASE: generate program code and database definitions.

Computer-Aided Software Engineering (contd.)
IS auditor considerations:
● CASE tools do not ensure requirements are met;
● CASE tools do not replace application development methodology;
● application changes must be reflected in stored CASE product data – change management;
● application controls need to be incorporated; and
● CASE repository needs to be secured.


Post implementation Review Objectives and Practices
Knowledge of post implementation review objectives and practices (e.g., project closure, control
implementation, benefits realization, performance measurement).
Explanation:
● Post implementation review is typically carried out in several weeks or months after project
completion, when the major benefits and shortcomings of the solution implemented will be
realized.
● Projects should be formally closed to: provide accurate information on project results, improve
future projects and allow an orderly release of project resources.
● The closure process should: determine whether project objectives were met or excused and
identify lessons learned to avoid mistakes and encourage repetition of good practices.
Main Area of Coverage: Post implementation Review

Post implementation Review
Post-implementation review verifies that the system was designed and developed properly and
proper controls were built into the system.
The objectives of post-implementation are:
● Assessing system adequacy:
o Were user requirements and management objectives met?
o Were access controls adequately defined and implemented?
● Reviewing program cost/benefit (ROI) requirements
● Providing recommendations for system inadequacies/deficiencies
● Providing implementation plans for recommendations

Post Implementation Review (contd.)
● Reviewing the development process:
o were chosen methodologies followed?
o was appropriate Program management used?
● Focus is to assess and critique the Program process
● Best performed by parties not involved in the Program
● Can be done internally by the Program development team and selected end-users

Quiz

QUIZ The phases and deliverables of a system development life cycle (SDLC) project should
be determined:
a. During the initial planning phases of the project
b. After early planning has been completed, but before work has begun
c. Throughout the work stages, based on risks and exposures
d. Only after risks and exposures have been identified and the IS auditor
has recommended appropriate controls

QUIZ The phases and deliverables of a system development life cycle (SDLC) project should
be determined:
a. During the initial planning phases of the project
b. After early planning has been completed, but before work has begun
c. Throughout the work stages, based on risks and exposures
d. Only after risks and exposures have been identified and the IS auditor
has recommended appropriate controls
Answer: a.
It is extremely important that the project be planned properly and that the specific phases
and deliverables be identified during the early stages of the project.
Copyright 2012-2014,Simplilearn,All rights reserved

QUIZ By evaluating application development projects against the capability maturity model
2 (CMM), an IS auditor should be able to verify that:
a. reliable products are guaranteed.
b. programmers' efficiency is improved.

c. security requirements are designed.
d. predictable software processes are followed.

QUIZ By evaluating application development projects against the capability maturity model
2 (CMM), an IS auditor should be able to verify that:
a. reliable products are guaranteed.
b. programmers' efficiency is improved.

c. security requirements are designed.
d. predictable software processes are followed.
Answer: d.
By evaluating the organization's development projects against the CMM, an IS auditor determines whether the development
organization follows a stable, predictable software process. Although the likelihood of success should increase as the software
processes mature toward the optimizing level, mature processes do not guarantee a reliable product. CMM does not evaluate
technical processes such as programming nor does it evaluate security requirements or other application controls.

QUIZ An IS auditor reviewing a proposed application software acquisition should ensure that
3 the:
a. operating system (OS) being used is compatible with the existing hardware platform.
b. planned OS updates have been scheduled to minimize negative impacts on company

needs.
c. OS has the latest versions and updates.
d. products are compatible with the current or planned OS.

QUIZ An IS auditor reviewing a proposed application software acquisition should ensure that
the:
3
a. operating system (OS) being used is compatible with the existing hardware platform.
b. planned OS updates have been scheduled to minimize negative impacts on company

needs.
c. OS has the latest versions and updates.
d. products are compatible with the current or planned OS.
Answer: d.
In reviewing the proposed application the auditor should ensure that the products to be purchased are compatible with the current or planned
OS. Regarding choice a, if the OS is currently being used, it is compatible with the existing hardware platform, because if it is not it would not
operate properly. In choice b, the planned OS updates should be scheduled to minimize negative impacts on the organization. For choice c, the
installed OS should be equipped with the most recent versions and updates (with sufficient history and stability).

QUIZ
Which of the following is an advantage of prototyping?
4
a. The finished system normally has strong internal controls.
b. Prototype systems can provide significant time and cost savings.

c. Change control is often less complicated with prototype systems.
d. It ensures that functions or extras are not added to the intended system.

QUIZ
Which of the following is an advantage of prototyping?
4
a. The finished system normally has strong internal controls.
b. Prototype systems can provide significant time and cost savings.

c. Change control is often less complicated with prototype systems.
d. It ensures that functions or extras are not added to the intended system.
Answer: b.
Prototype systems can provide significant time and cost savings; however, they also have several
disadvantages. They often have poor internal controls, change control becomes much more complicated,
and it often leads to functions or extras being added to the system that were not originally intended.

Summary
Here is a quick • Key elements of information security management include: senior

recap of what we
management commitment and support, policies and procedures,
have learned in this
domain: organization, security awareness and education, monitoring and
compliance, and incident handling and response.
• General points of logical entry into a system should be understood,

including logical protection at the network, platform, database and
application layers.
• It is important to know best practices for identification and authentication.

This includes practices for handling default system accounts, normal user
accounts and privileged user accounts.

Summary (contd.)
Here is a quick • Protection of information assets includes the key components that ensure
recap of what we
confidentiality, integrity and availability (CIA) of information assets.
have learned in this
domain: • The evaluation design, implementation and monitoring of logical and
physical access controls to ensure CIA.
• Network infrastructure security, environmental controls and processes and

procedures used to store, retrieve, transport and dispose of confidential
information assets.

This concludes the domain on IS acquisition, development, and implementation
The next domain covers IS operation, maintenance, and support.
An ISACA® Certification based on CISA® 2014 Curriculum.

Copyright 2014, Simplilearn, All rights reserved.

CISA - Domain 3 - IS Acquisition, Development and Implementation

Uploaded by

Document Informationclick to expand document information

Document Informationclick to expand document information

Copyright:

Available Formats

CISA - Domain 3 - IS Acquisition, Development and Implementation

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CISA - Domain 3 - IS Acquisition, Development and Implementation

Uploaded by

Copyright:

Available Formats

Certified Information System Auditor (CISA®)

Domain 03: IS Acquisition, Development, and Implementation

An ISACA® Certification based on CISA® 2014 Curriculum.

2 Copyright 2012-2014, Simplilearn, All rights reserved.

3 Copyright 2012-2014, Simplilearn, All rights reserved.

Copyright 2012-2014, Simplilearn, All rights reserved.

Knowledge Statement 3.1

5 Copyright 2012-2014, Simplilearn, All rights reserved.

The main areas covered under this knowledge statement include:

6 Copyright 2012-2014, Simplilearn, All rights reserved.

7 Copyright 2012-2014, Simplilearn, All rights reserved.

This review must be part of governance and management of projects.

8 Copyright 2012-2014, Simplilearn, All rights reserved.

9 Copyright 2012-2014, Simplilearn, All rights reserved.

A business case should:

● answer the question, “Why should this project be undertaken?”

● be reviewed to ensure that it is still valid.

10 Copyright 2012-2014, Simplilearn, All rights reserved.

A feasibility study in business case development:

11 Copyright 2012-2014, Simplilearn, All rights reserved.

A feasibility study involves an assessment of:

12 Copyright 2012-2014, Simplilearn, All rights reserved.

13 Copyright 2012-2014, Simplilearn, All rights reserved.

Disadvantages of Traditional SDLC Phases are listed here:

14 Copyright 2012-2014, Simplilearn, All rights reserved.

Design involves developing blueprints of the system and its components :

Components or modules of design are as follows:

15 Copyright 2012-2014, Simplilearn, All rights reserved.

16 Copyright 2012-2014, Simplilearn, All rights reserved.

SDLC testing ensures that:

General testing levels are:

17 Copyright 2012-2014, Simplilearn, All rights reserved.

● System testing: collective constitution of the programs/modules as one system:

● Final acceptance testing done during implementation, and considers:

18 Copyright 2012-2014, Simplilearn, All rights reserved.

Following are the terminology frequently used in software testing:

19 Copyright 2012-2014, Simplilearn, All rights reserved.

● Function/validation testing: testing functionality against detailed requirements;

● Sociability testing: evaluating impact on existing systems or environment; and

● Automated application testing:

20 Copyright 2012-2014, Simplilearn, All rights reserved.

The SDLC implementation phase involves the following activities:

● Certification: Meeting minimum security requirements as set by the organization. An assessor

● Accreditation: A senior official in management takes up responsibility and accountability of using

● Certification and accreditation ensures effectiveness at:

o provide management accountability on systems effectiveness in meeting intended business objectives.

21 Copyright 2012-2014, Simplilearn, All rights reserved.

● The final step in implementation is migration to production/live environment, during which:

o procedures are documented and in place;

o necessary data is converted into the new system; and

o user training is completed.

22 Copyright 2012-2014, Simplilearn, All rights reserved.

An implementation plan indicates:

Phase 1: Develop to-be support structures Phase 2: Establish support functions

23 Copyright 2012-2014, Simplilearn, All rights reserved.

25 Copyright 2012-2014, Simplilearn, All rights reserved.

Copyright 2012-2014, Simplilearn, All rights reserved.