CISA Training - Chapter 3 - 2016

2016 CISA® Review Course
Hafiz Sheikh Adnan Ahmed – CISA, COBIT 5, ISO 27001 LA
[PECB Certified Trainer]

Quick Reference Review
• Benefits Realization
• Projects, Programs and Portfolio
• Management practices of specific IT processes
• SDLC Process
• System development, acquisition and maintenance methodology

3.2 Benefits Realization
• A compromise among major factors such as cost, quality, development/delivery
time, reliability and dependability
• IS auditor to understand how business defines value or ROI for development-
related projects

3.2.1 Portfolio/Program Management
• Program:
• A group of relevant projects and time-bound tasks that are closely linked together through common objectives,
common budget, knotted schedules and strategies
• Have limited time frame and organizational boundaries
• More complex, usually have a longer duration, a higher budget, and higher risks
• Program Management:
• Objective is the successful execution of programs
• Management of program scope, program financials, schedules, objectives and program deliverables
• Program context and environment
• Program communication and culture
• Program organization
• Portfolio:
• All the projects being carried out in an organization in a given point in time (Snapshot!)
• Projects may NOT be closely linked together as in the case of Program Management

• Project Management Office (PMO):
• Owner of project management and program management process
• Provide professional support to maintain current and develop new procedures and standards
• Objective is to improve projects and program management quality and secure project success
• Focus on activities and tasks and NOT on project and program content

3.2.2 Business Case Development & Approval
• Provides the information required for an organization to decide whether a project should
proceed
• Normally derive from a feasibility study undertaken as part of project initiation/planning
• Feasibility study scope the problem, identify and explore a number of solutions, and make
recommendations on what action to take
• Business case is part of outlining the numbers of options
• Describe the justification for setting up and continuing a project
• Provide the “reasons” for the projects and answer: “Why should this project be undertaken?”
• If business case is changed during the course of the project,
the project should be reapproved through planning and approval process

3.2.3 Benefits RealizationTechniques
• Benefits do not just happen when the new technology is delivered; they occur throughout the
business cycle
• A planned approach to benefits realization is required
• It requires:
• Describing benefits management or benefits realization
• Assigning a measure and target
• Establishing a tracking/measuring regimen
• Documenting the assumption
• Establishing key responsibilities for realization
• Validating the benefits predicted in the business
• Planning the benefit that is to be realized
• A continuous process that must be managed just like any business process
• Often includes a post-implementation review 6-18 months after the implementation of systems
• Must be part of governance and management of projects

3.3 Project Management Structure
• Many approaches to project management exist
• Some focus on software development, some concentrate on a holistic and
systemic view
• Project Management Body of Knowledge (PMBOK)
• Projects in a Controlled Environment (PRINCE 2)
• International Project Management Association (IPMA)

3.3.1 General Aspects
• A project is a time-bound effort
• A project can be complex
• A project has specific objectives, deliverables, and start and end dates
• Projects are divisible into explicit phases

3.3.2 Project Context and Environment
• A project can be divided into a time and a social context
• This includes:
• Importance of the project in the organization
• Connection between the organization’s strategy and the project
• Relationship between the projects and other projects
• Connection between the project to the underlying business case
• Project represents a social system
• Social environments needs to be considered with project relationship

3.3.3 Project Organizational Forms
1. Influence Project Organization
• The Project Manager (PM) has only a staff function without formal management
authority
• PM only allowed to advise peers and team members as to which activities should
be completed
2. Pure Project Organization
• PM has formal authority over those taking part in the project
3. Matrix Project Organization
• Management authority is shared between the PM and the department heads

• Requests for major projects submitted to and prioritized by IS Steering Committee
• PM appointed by IS Steering Committee
• PM to be given complete operational control over the project and be allocated the
appropriate resources
• IS auditors may be included in the project team as a control expert
• IS auditors may provide independent, objective review
• IS auditors may participate on the project in an advisory role

3.3.4 Project Communication and Culture
• Communication when initiating the project management project process may be achieved by:
• One-on-One meetings
• Kick-Off meetings
• Project start workshops
• A combination of the three
• Each project has its own culture that defines its norms and rules of engagement
• Methods for developing a project culture include:
• Establishment of a project mission statement
• Project name and logo
• Project office or meeting place
• Project intranet
• Project team meeting rules and communication protocol
• Project specific social events

3.3.5 Project Objectives
• A project needs results that are SMART (Specific, Measurable, Attainable, Realistic, Timely)
• A comprehensive project view ensures consolidation of all closely coupled objectives
• Objectives are broken down into main objectives, additional objectives and non-objectives
• Main Objectives to be directly coupled with business success
• Additional Objectives not directly related to the main results of the project but contribute to
project success
• Non-Objectives add clarity to scope, and project boundaries become clearer
• Common approach to define project objectives is “Object Breakdown Structure (OBS)”
• Represents the individual components of the solution and their relationships to each other in
hierarchical manner
• After OBS, a “Work Breakdown Structure (WBS)” is designed to structure all the tasks that are
necessary to build up the elements of the OBS during the project
• WBS represents the project in terms of manageable and controllable units of work
• Serves as a central communication tool
• Forms the baseline for cost and resource planning

• WBS show individual work packages (WPs)
• Structuring of the WBS is process-oriented and in phases
• Each WP must have a distinct owner and a list of objectives
• WP specifications should include dependencies on other WPs

3.3.6 Roles and Responsibilities of Groups &
Individuals
• Senior Management:
• Demonstrates commitment to the project and approves necessary resources to complete the project
• User Management:
• Assumes ownership of the project and resulting system, allocating qualified representatives to the team
• Actively participates in business process redesign, system requirements definition, test case
development, acceptance testing and user training
• Review and approve system deliverables
• Project Steering Committee:
• Provides overall direction and ensures representation of major stakeholders in the project’s outcome
• Ultimately responsible for all deliverables, project costs and schedules
• Project Sponsor:
• Provides funding for the project
• Works closely with the PM to define CSF & metrics for measuring the success of the project

• Systems Development Management:
• Provides technical support for hardware and software environments by developing, installing and
operating the requested system
• Provides assurance that the system is compatible with the organization’s computing environment and
strategic IT direction
• Project Manager:
• Provides day-to-day management and leadership of the project
• Facilitate the definition of the scope of the project, manage the budget, and control activities
• Systems Development Project team:
• Completes assigned tasks, communicates effectively with users
• Security Officer:
• Ensures system controls and processes provide an effective level of protection
• Reviews security test plans
• Evaluates security-related documents
• Periodically monitors the security system’s effectiveness during its operational life

• Quality Assurance (QA):
• Review results and deliverables within each phase
• Confirm compliance with requirements
• Propose recommendations for process improvements
• Report to management on systems that are not performing as defined or
designed

3.4 Project Management Practices
• Project Management is the application of knowledge, skills, tools and techniques to a broad range
of activities to achieve a stated objective such as meeting the defined user requirements, budget
and deadlines for an IS project
• Component processes include:
• Initiating, Planning, Executing, Controlling, and Closing a Project
• Iterative in nature, risk-based management process
• Project Management should pay attention to three key elements:
• Deliverables
• Duration
• Budget
• There will be positive correlation between highly demanding deliverables, a long duration and a
high budget

3.4.1 Initiation of a Project
• Approval of a project initiation document (PID) or a project request document
(PRD) is authorization for a project to begin

3.4.2 Project Planning
• Software development/acquisition or maintenance projects have to be planned and controlled
• First step is to identify resources for software development
• Estimate and budget software development resources
• Several techniques:
• Software Size Estimation:
• Estimate to be used to guide allocation of resources and to judge the time and cost required for its
development
• Using single-point estimations such as SLOC (source lines of code)
• Function Point Analysis (FPA):
• Measure of the size of an information system based on the number and complexity of the inputs,
outputs, files, interfaces and queries

• Critical Path Methodology (CPM):
• A path through the network is any set of successive activities which go from the beginning to the end of
the project
• The Critical Path is the sequence of activities whose sum of activity time is longer than that for any
other path through the network
• Gives the shortest possible completion time for the overall project
• Gantt Charts:
• Constructed to aid in scheduling the activities needed to complete a project
• Shows when an activity should begin and when to end
• Reflect the resources assigned to each task and by what percent allocation
• Used to track the achievement of milestones or significant accomplishments for the project

• Program Evaluation Review Technique (PERT):
• Often used in system development projects with uncertainty about the duration
• A CPM-type technique which uses three different estimates of each activity
• Optimistic – If everything goes well
• Pessimistic – Worst-case scenario
• Most Likely
• The following calculation is applied:
[Optimistic + Pessimistic + 4(most likely)]/6
• CPM is also derived from PERT
• The first step is to identify all the activities and related events/milestones of the project and their
relative sequence

• Time box Management:
• Define and deploy software deliverables within a relatively short and fix period
of time, and with predetermined specific resources
• Used to accomplish prototyping or RAD approach
• It prevents project cost overruns and delays from scheduled delivery

3.4.3 Project Controlling
• Activities include management of scope, resource usage and risk
• Management of Scope Changes:
• Changes to scope lead to change in deadlines, budget
• Through Change Management Process
• Management of Resource Usage:
• A process by which project budget is spent
• Management of Risk:
• Risk is a negative event that would disrupt relevant aspects of the project
• Includes:
• Identify Risk
• Assess and Evaluate Risk
• Manage Risk
• Monitor Risk
• Evaluate the Risk Management process

3.4.4 Closing a Project
• Project sponsor to be satisfied and accept the delivery of the system
• Conduct post-project review
• Conduct post-implementation review once the system in production for quite
some time

3.5 Business Application Development
• The implementation process (SDLC) for business applications, begin with feasibility study
• Critical business objectives and associated application objectives to be defined
• Risk assessment to be performed at all stages of application development
• Testing to be performed at all stages of application development
• Verification and Validation model (V-Model) emphasize the relationship between development
and testing
• IS auditor to review all areas and phases of systems development project, and report
independently to management
• IS auditor to provide an evaluation of the methods and techniques applied through development
phases of the business application life cycle

3.5.1Traditional SDLC Approach
• A waterfall technique, the oldest and most widely used for developing business
applications
• Based on a systematic, sequential approach to software development
• Begins with feasibility study and progresses through requirements definition,
design, development, implementation and post-implementation

3.5.2 Description ofTraditional SDLC Phases

3.5.3 Integrated Resource Management
Systems
• Usually called ERP solutions
• Organizations to convert management philosophies, policies and practices to implement ERP and
Integrated solutions
• Impact and risk assessment must be conducted
• Organizations either to implement the solution As-Is, Out-of-the-box (Vanilla solutions); or
customize based on the requirements

3.5.4 Risk associated with Software Development
• Many potential risks when designing and developing software systems
• Business Risk – Likelihood that new system may not meet the users’ business needs, requirements and
expectations
• Project Risk – Project activities to design and develop the system exceeds the limits of the financial
resources set aside for the project
• Supplier Risk – Failure to communicate clearly the requirements and expectations, resulting in suppliers
delivering late
• Stakeholders Risk – Not providing needed inputs
• Technology Risk – Inefficient and non-compatible technology
• IS auditor to review project goals, objectives
• IS auditor to review Scope, Software development and design activities
• IS auditor to conduct periodic review and risk analysis for each project phase

3.6 Business Application Systems
• IS auditor to obtain clear understanding of the application systems under review
• The applications range from traditional applications to industry specific

3.6.1 Electronic Commerce
• Business-to-Consumer (B-to-C) Relationships
• Business-to-Business (B-to-B) Relationships
• Business-to-Employee (B-to-E) Relationships
• Business-to-Government (B-to-G) Relationships

E-Commerce Risks
• Confidentiality
• Integrity
• Availability
• Authentication

3.6.2 Electronic Data Interchange
• EDI replaces the traditional paper documents exchange
• Purchase orders, invoices etc.
• EDI requires communication software, translation software and access to
standards
• Communication software moves data from one point to another
• Translation software helps build a map and shows how the data fields from the
application correspond to elements of an EDI standard

3.6.4 Controls in EDI Environment
• Data encryption
• Electronic signatures
• Message authentication codes

3.6.5 Electronic Mail (E-Mail)
Security Issues:
• Flaws in the configuration of the mail server
• Denial-of-Service (DoS) attacks
• Sensitive information transmitted unencrypted
• Viruses
• Legal exposure

3.6.6 Point-of-Sale Systems
This includes:
• Credit and Debit Cards; optical scanners; bar code readers etc
IS auditor to determine:
• Credit cardholder information is stored on the local POS systems

3.6.7 Electronic Banking
Main issues involved:
• Strategic, Operational and Reputational
Risk Management Controls:
• Board and Management oversight
• Security Controls
• Legal and Regulatory Risk Management

3.6.8 Electronic Finance
Enable new providers to emerge within and across countries, including online banks,
brokerages and companies that allow consumers to compare financial services
Advantages include:
• Lower costs
• Widening access to financial services
• Increased breadth and quality

AutomatedTeller Machine (ATM)
Recommended controls include:
• Written policies and procedures covering personnel, security controls, operations,
disaster recovery
• Procedures for PIN issuance
• Procedures for the security of PINs delivery
• Audit trails of transaction logs

Audit of ATM includes:
• Review measures to establish proper customer identification and maintenance of
their confidentiality
• Review segregation of duties
• Review exception reports to provide an audit trail

3.7 Development Methods
• Different techniques of understanding, designing and constructing a software
system

3.7.1 Use of Structured Analysis,
Design & DevelopmentTechniques
• Closely related to traditional SDLC
• Develop system context diagrams (e.g. high-level process flow schema)
• Develop data dictionaries
• Define external events

3.7.3 Prototyping-Evolutionary Development
• Evolutionary development model, creating a system through trial and error
procedures
• Enables the developer and customer to understand and react to risk at each
evolutionary level
• Combines the best features of SDLC by maintaining systematic stepwise approach,
but incorporates it into an iterative framework that more realistically reflects the
real world

3.7.4 Rapid Application Development (RAD)
• A methodology that enables organizations to develop strategically important
systems quickly while reducing development costs and maintaining quality
• Four major stages:
• Concept definition stage
• Functional design stage
• Development stage
• Deployment stage

Web-Based Application Development
• Web-based application development & associated XML technologies
• SOAP, WSDL, UDDI are some of the standards for web-based application
development

Software Reengineering
• A process of updating an existing system by extracting and reusing design and
program components

Reverse Engineering
• A process of studying and analyzing an application, a software application or a
product to see how it functions and to use that information to develop a similar
system
• Decompiling object or executable code into source code and using it to analyze the program
• Black box testing the application to unveil its functionality

3.8 Infrastructure Development/
Acquisition Practices
Steps to choose the right architecture:
• To successfully analyze the existing architecture
• To design a new architecture that takes into account the existing architecture and
a company’s particular requirements
• To write functional requirements of this new architecture
• To develop a proof of concept based on these functional requirements

3.8.1 Project phases of Physical Architecture
Analysis

3.8.2 Planning Implementation of Infrastructure

3.8.3 Critical Success Factors (CSF)

3.8.4 Hardware Acquisition
• When acquiring a system, the specification include:
• Information processing requirements
• Hardware requirements
• Major existing application systems and future application systems
• System software requirements

3.8.5 System Software Acquisition
• Business and technical issues to consider when acquiring a system software

3.8.6 System Software Implementation

3.9 Information Systems Maintenance
Practices
• Refer to the process of managing change to application systems while maintaining the integrity of
both the production source and executable code
• A standard process for performing and recording changes is necessary
• Process typically established in the design phase of the application when application system
requirements are baselined

3.9.1 Change Management Process Overview
• Process begins with authorizing changes to occur
• Usually initiated from end users as well as operational staff and system
development/maintenance staff
• CRs to be in a format that ensures all changes are considered for action and allows the system
management staff to easily track the status of the request
• Authorization must be given before putting any change in the production
• Programmers should NOT have write, modify, or delete access to production data
Deploying Changes:
• Deploy the changes only after the user is satisfied with system test results and the adequacy of
the system documentation
Documentation:
• All relevant system documentation to be updated
• Procedures to be in place to ensure documentation placed offsite for DR purposes to be updated

Auditing Program Changes:
• IS auditor to ensure that controls are in place to protect production application programs from
unauthorized changes
• Ensure that:
• Access to program libraries should be restricted
• Supervisory reviews should be conducted
• Change requests should be approved and documented
• Potential impact of changes should be accessed
Emergency Changes:
• To resolve system problems and enable critical “production job” processing to continue
• Typically involve the use of special logon IDs

3.9.2 Configuration Management
• In a Configuration Management system, maintenance requests must be formally documented and
approved by a Change control Group
• Involves procedures throughout the software life cycle to identify, define and baseline software
items in the system and provide a basis for problem management, change management and
release management
• Process involves identification of items that are likely to change (called CIs)

3.10 System DevelopmentTools &
Productivity Aids
• Include code generators, Computer-Aided Software Engineering (CASE) applications, Fourth-
Generation Languages (4GL)

3.10.1 Code Generators
• Generate program code based on parameters defined by a systems analyst
• Allow programmers and developers to implement software programs with efficiency

3.10.2 Computer-Aided Software Engineering
(CASE)
• CASE is the use of automated tools to aid in the software development process
• Use the application of software tools for software requirements captures and analysis, software
design, code production, testing, document generation and other software development
activities

• CASE products enforce a uniform approach to system development, facilitate storage and retrieval
of documents, and reduce the manual effort in developing and presenting system design
information
• CASE tools help in the application design process
• CASE tools should complement and fit into the application development methodology
• Changes to the application should be reflected in stored CASE product data

3.11 Process Improvement Practices
• Business processes require improvements, which are accomplished with practices and
techniques:
• Business process re-engineering and process change projects
• ISO 9126
• CMMI
• ISO/IEC 15504

3.11.1 Business Process Re-Engineering (BPR) &
Process Change Projects
• A process of responding to competitive and economic pressures, and customer demands to
survive in the current business environment
• BPR achieved with the help of implementing an ERP system
• Steps in a successful BPR are:
• Define the areas to be achieved
• Develop a project plan
• Gain an understanding of the process under review
• Redesign and streamline the process
• Implement and monitor the new process
• Establish a continuous improvement process
• IS auditor’s task is to identify the existing key controls and evaluate the impact of removing these
controls

Benchmarking Process
• Benchmarking is about improving business processes
• Defined as a continuous, systematic process for evaluating the products, services or work
processes of organizations recognized as a world-class “reference” in a globalized world for the
following:
• Comparing and Ranking
• Strategic Planning, SWOR (Strengths, Weaknesses, Opportunities, Risks)
• Investment decisions, company takeovers, mergers
• BPR
• Steps for a benchmarking exercise:
• Plan:
• Critical processes are identified
• Identify kinds of data and how data need to be collected

• Research:
• Collect baseline data about the processes of its organization before collecting these data
about other organizations
• Identify the reference products or companies
• Observe:
• Collect data and visit the benchmarking partner
• Analyze:
• Summarize and interpret the data collected, and analyze the gaps between an organization’s
process and it’s partner’s process
• Convert key findings into new operational goals
• Adopt:
• Translate the findings into a few core principles and work down from principles to strategies
to action plans
• Improve:
• Links each process in an organization with an improvement strategy and organizational goals

BPR Audit and Evaluation
• IS auditors must determine that:
• Organization’s change efforts are consistent with the overall culture and strategic plan of the
organization
• The reengineering team is making an effort to minimize any negative impact the change
might have on the organization’s staff
• The BPR team has documented lessons to be learned after the completion of the BPR

3.11.2 ISO 9126
• Assess the quality of software products
• Provides the definition of the characteristics and associated quality evaluation process to be used when
specifying the requirements for, and evaluating the quality of, software products throughout the life
cycle
• Attributes evaluated include:
• Functionality – Set of attributes that bears on the existence of a set of functions and their specified
properties
• Reliability – Set of attributes that bears on the capability of software to maintain its level of
performance under stated conditions for a stated period of time
• Usability – Set of attributes that bears on the effort needed for use and on the individual
assessment of such use by a stated or implied set of users
• Efficiency – Set of attributes that bears on the relationship between the level of performance of the
software and the amount of resources used under stated conditions
• Maintainability – Set of attributes that bears on the effort needed to make specified modifications
• Portability – Set of attributes that bears on the ability of software to be transferred from one
environment to another

3.11.3 Capability Maturity Model Integration
(CMMI)
• Describe five maturity levels
• Used to evaluate management of a computer center, the development function management
process, and implement and measure the IT change management process

3.11.4 ISO/IEC 15504
• Provide guidance on process improvement, benchmarking and assessment
• Generic practices, style guides and performance indicators of process capability are included for
each process
• Process capability is expressed in terms of process attributes grouped into capability levels
• Capability level is determined on the basis of achievement of specific process attributes
• Six capability levels
• Level 0 Incomplete Process
• Process is not implemented or fails to achieve its process attribute
• Little or no evidence of any systematic achievement of the process purpose
• Level 1 Performed process
• Implemented process achieves its process purpose
• Level 2 Managed Process
• Previously described performed process is now implemented in a managed fashion (planned, monitored, adjusted)
• Work products are appropriately established, controlled and maintained

• Level 3 Established process
• Previously described managed process is now implemented using a defined process that is capable of achieving its
process outcomes
• Level 4 Predictable process
• Previously described established process now operates within defined limits to achieve its process outcomes
• Level 5 Optimizing process
• Previously described predictable process is continuously improved to meet relevant current and projected business
goals

3.12 Application Controls
• The controls over input, processing and output functions
• They include methods for ensuring 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
• May consist of edit tests, totals, reconciliations, and identification and reporting of incorrect,
missing or exception data
• Help ensure data accuracy, completeness, validity, verifiability, and consistency

• IS auditor’s tasks include the following:
• Identify the significant application components and the flow of transactions through the system
• Gain an understanding of the application by reviewing the available documentation and interviewing appropriate
personnel
• Develop a testing strategy
• Test the controls to ensure their functionality and effectiveness by applying appropriate audit procedures

3.12.1 Input/Origination Controls
• Ensure that every transaction to be processed is entered, processed and recorded accurately and
completely
• Ensure only valid and authorized information is input
Input Authorization:
• Verifies that all transactions have been authorized and approved by management
• Helps ensure that only authorized data are entered for processing by applications
• Unique passwords; source documents
Batch controls and Balancing:
• Batch controls group input transactions to provide control totals
• Based on total monetary amount, total items, total documents or hash totals
• Total monetary amount; total items; total documents

Error Reporting and Handling:
• Controls be identified to verify that only correct data are accepted into system and input errors
are recognized and corrected
• Corrections to data should be processed through normal data conversion processes and should be
verified, authorized and reentered into the system as a part of the normal processing
• Transaction log; reconciliation of data; error correction procedures

3.12.2 Processing Procedures & Controls
• Ensure the reliability of application program processing
Data Validation and Editing Procedures:
• Ensure input data is validated and edited as close to the time and point of origination as possible
• Editing controls are preventive controls that are used in a program before data are processed
Processing Controls:
• Ensure the completeness and accuracy of accumulated data
• Manual recalculations; run-to-run totals; limit checks on amounts
Data File Control Procedures:
• Ensure that only authorized processing occurs to stored data

3.12.3 Output Controls
• Provide assurance that the data delivered to users will be presented, formatted and delivered in a
consistent and secure manner
• Report distribution; output error handling; verification of receipt of reports

3.12.4 Business Process Control Assurance
• Evaluate controls at the process and activity levels
• May be a combination of management, programmed and manual controls
• Business process owner-specific controls
• Process maps
• Process controls
• Assessing business risks within processes
• Roles and responsibilities
• Activities and tasks

3.13 Auditing Application Controls
IS auditor’s tasks include the following:
• Identify the significant application components
• Gain a detailed understanding of the application
• Identify strong controls and evaluate the impact of weak controls on the applications
• Review application system documentation to provide an understanding of the
functionality of the application
Documents to Review:
• System development methodology documents
• Functional design specification
• Program changes
• User manuals
• Technical reference documentations

3.13.2 Risk Assessment Model to analyze
Application Controls
Risk Assessment based on many factors:
• The quality of internal controls
• Economic conditions
• Complexity of operations
• Recent changes in key positions
• Staff turnover
• Prior audit results
• Transaction volume
• Impact of application failure

3.13.3 Observing &Testing User Performing
Procedures
• Segregation of duties:
• Ensure no individual has the capability of performing more than one parallel
processes
• Authorization of Input:
• Written authorization on input documents or with the use of unique
passwords
• Balancing:
• Verify that run-to-run totals are reconciled
• Distribution of Reports:
• Reports produced and maintained in a secure manner

3.13.4 Data IntegrityTesting
• Examines accuracy, completeness, consistency and authorization of data
• Indicate failures in input or processing controls

3.13.5 Data Integrity in OnlineTransaction
Processing Systems
• Online data integrity requirements follow ACID principle:
1. Atomicity (A):
1. A transaction is either completed in its entirety OR not at all
2. If error occurs, all changes made up to that point are backed out
2. Consistency (C):
1. Integrity conditions are maintained with each transaction
3. Isolation (I):
1. Each transaction is isolated from other transactions
4. Durability (D):
1. If a transaction has been reported back to a user as complete, the resulting changes to the
DB survive subsequent hardware or software failures

3.13.6Test Application Systems
• Involves analyzing computer application programs, testing computer application program controls,
selecting and monitoring data process transactions
• IS auditor may use GAS (Generalized Audit Software) as tool
• Useful when specific application control weaknesses are discovered
• Perform parallel simulation
• Compare expected outcomes to live data

3.13.7 Continuous Online Auditing
• IS auditors to monitor the operation on a continuous basis and gather selective audit evidence
• Used in time-sharing environments that process a large number of transactions
• Improve security of a system
• When a system is misused, a continuous audit technique will report in a timely fashion
• This reduces LAG time between the misuse of the system and the detection of that misuse is
reduced

3.13.8 Online AuditingTechniques
1. SCARF/EAM
1. This involves embedding specially written audit software in the organization’s host application system so the
application systems are monitored on a selective basis
2. Audit Hooks
1. Embed hooks in application systems to function as red flags and to induce IS auditors to act before an error
or irregularity gets out of hand
3. Integrated Test Facility (ITF)
1. Dummy entries are set up and included in an auditee’s production files
2. IS auditors process transactions during regular processing times to
compare the output to verify the correctness of the computer-processed data

3.14 Auditing Systems Development,
Acquisition & Maintenance
IS auditor’s tasks include the following:
• Meet with key systems development and user project team members to
determine main components, objectives and user requirements to identify areas
that need controls
• Discuss selection of appropriate controls with systems development and user
project team members
• Evaluate available controls and advise the project team regarding the design of the
system and implementation of controls
• Review documentation and deliverables to monitor the system development
process to ensure controls are implemented
• Participate in post implementation reviews

3.14.1 Project Management
IS auditor to review:
• Risk Management methods within the project
• Associated risks and exposures inherent in each phase of the SDLC
• Project team’s ability to produce key deliverables by the promised dates
• Issue management
• Reporting processes
• Change control procedures
• Stakeholder management involvement
• Sign off process

3.14.2 Feasibility Study
IS auditor to perform:
• Review of the documentation produced
• Whether all cost justifications/benefits are verifiable
• Identify and determine the criticality of the need of application
• Determine the reasonableness of the chosen solution

3.14.3 Requirements Definition
IS auditor to perform the following:
• Verify the accuracy of RS document
• Verify all affected team groups have appropriate representation
• Verify project initiation and cost have received proper management approval
• Review the conceptual design specifications

3.14.4 Software Acquisition Process
• Analyze the documentation to determine whether decision to acquire a solution is appropriate
• Review the RFP
• Determine whether selected vendor is supported by RFP documentation
• Review vendor contracts
• Ensure legal and government regulations are compliant

3.14.5 Detailed Design and Development
• Review system flowcharts
• Verify appropriate approvals obtained for any or all changes
• Review input, processing and output controls designed into the system for appropriateness
• Interview the key users of the system
• Verify the integrity of key calculations and processes
• Review the quality assurance results of the programs developed

3.14.6Testing
• Review test plans for completeness
• Review error reports
• Interview end users of the system for their understanding of new methods, procedures
• Review system and end user documentation
• Verify system security is incorporated
• Review test plans, test cases and test results

3.14.7 Implementation Phase
• Review all system documentation to ensure completeness
• Verify release plans and associated documents

3.14.8 Post-Implementation Phase
• Determine if system objectives were achieved and requirements met
• Determine if cost benefits identified earlier are being measured
• Review change requests to assess the type of changes required for the system
• Review if controls implemented are functioning properly

3.14.9 System Change Procedures &
the Program Migration Process
• The existence and use of a methodology for authorizing, prioritizing and tracking system
change requests from the user
• Whether emergency change procedures are addressed in the manuals
• The user’s satisfaction
• The adequacy of the organization’s procedures for dealing with emergency program changes

Self-Assessment Questions
1. Which of the following weaknesses would be considered MOST
serious in Enterprise Resource Planning (ERP) software used by a
bank?
a) Access controls have not been reviewed
b) Limited documentation is available
c) Two year old backup tapes have not been replaced
d) Database backups are performed once a day

2. When auditing the requirements phase of a software acquisition, the
IS should:
a) Assess the feasibility of the project timetable
b) Assess the vendor’s proposed quality processes
c) Ensure that the best software package is required
d) Review the completeness of the specifications

3. User specifications for a project using the traditional SDLC
methodology has not been met. An IS auditor looking for a cause
should look in which of the following areas?
a) Quality assurance
b) Requirements
c) Development
d) User training

Answers
1. a) Access controls have not been reviewed
2. d) Review the completeness of the specifications
3. c) Development

CISA Training - Chapter 3 - 2016

CISA Training - Chapter 3 - 2016

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (16)

Similar to CISA Training - Chapter 3 - 2016

Similar to CISA Training - Chapter 3 - 2016 (20)

Recently uploaded

Recently uploaded (20)

CISA Training - Chapter 3 - 2016