Trust in, and value from, information systems - PowerPoint PPT Presentation

Loading...

PPT – Trust in, and value from, information systems PowerPoint presentation | free to download - id: 69923a-YmZhN



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Trust in, and value from, information systems

Description:

isaca trust in, and value from, information systems – PowerPoint PPT presentation

Number of Views:7
Avg rating:3.0/5.0
Date added: 23 April 2019
Slides: 175
Provided by: isaca
Learn more at: http://eturksoft.com
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Trust in, and value from, information systems


1
Trust in, and value from, information systems
  • ISACA

2
Chapter 3Information Systems Acquisition,
Development and Implementation
  • 2012 CISA? Review Course

3
Course Agenda
  • Learning Objectives
  • Discuss Task and Knowledge Statements
  • Discuss specific topics within the chapter
  • Case studies
  • Sample questions

4
Exam Relevance
  • Ensure that the CISA candidate
  • Understands and can provide assurance that the
    practices for the acquisition, development,
    testing and implementation of information systems
    meet the enterprises strategies and objectives.
  • The content area in this chapter will represent
    approximately 19 of the CISA examination
    (approximately 38 questions).

5
Learning Objectives
  • Evaluate the business case for proposed
    investments in information systems acquisition,
    development, maintenance and subsequent
    retirement to determine whether it meets business
    objectives.
  • Evaluate the project management practices and
    controls to determine whether business
    requirements are achieved in a cost-effective
    manner while managing risks to the organization.
  • Conduct reviews to determine whether a project is
    progressing in accordance with project plans, is
    adequately supported by documentation and status
    reporting is accurate.

6
Learning Objectives(continued)
  • Evaluate controls for information systems during
    the requirements, acquisition, development and
    testing phases for compliance with the
    organizations policies, standards, procedures
    and applicable external requirements.
  • Evaluate the readiness of information systems for
    implementation and migration into production to
    determine whether project deliverables, controls
    and the organizations requirements are met.
  • Conduct postimplementation reviews of systems to
    determine whether project deliverables, controls
    and the organizations requirements are met.

7
3.2.1 Portfolio/Program Management
  • A program is a group of projects and time-bound
    tasks that are closely linked together through
    common objectives, a common budget, intertwined
    schedules and strategies
  • Programs have a limited time frame (start and end
    date) and organizational boundaries

8
3.2.1 Portfolio/ProgramManagement (continued)
  • Methodology and processes used in program
    management are similar to those in project
    management and run parallel to each other
  • To formally start a program, some form of written
    assignment from the program owner to the program
    manager/team is necessary

9
3.2.1 Portfolio/Program Management (continued)
  • The objectives of project portfolio management
    are
  • Optimization of the results of the project
    portfolio
  • Prioritizing and scheduling projects
  • Resource coordination (internal and external)
  • Knowledge transfer throughout the projects

10
3.2.2 Business Case Development and Approval
  • A business case provides the information required
    for an organization to decide whether a project
    should proceed
  • The initial business case normally derives from a
    feasibility study as part of project planning
  • The business case should be of sufficient detail
    to describe the justification for setting up and
    continuing a project

11
3.2.3 Benefits RealizationTechniques
  • Benefits realization requires
  • Describing benefits management or benefits
    realization
  • Assigning a measure and target
  • Establishing a tracking/measuring regime
  • Documenting the assumption
  • Establishing key responsibilities for realization
  • Validating the benefits predicted in the business
  • Planning the benefit that is to be realized

12
3.3.1 General Aspects
  • IS projects may be initiated from any part of an
    organization
  • A project is always a time-bound effort
  • Project management should be a business process
    of a project-oriented organization
  • The complexity of project management requires a
    careful and explicit design of the project
    management process

13
3.3.2 Project Context and Environment
  • A project context can be divided into a time and
    social context. The following must be taken into
    account
  • Importance of the project in the organization
  • Connection between the organizations strategy
    and the project
  • Relationship between the project and other
    projects
  • Connection between the project to the underlying
    business case

14
3.3.3 Project Organizational Forms
  • Three major forms of organizational alignment for
    project management are
  • Influence project organization
  • Pure project organization
  • Matrix project organization

15
3.3.4 Project Communication and Culture
  • Depending on the size and complexity of the
    project and the affected parties, 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

16
3.3.5 Project Objectives
  • A project needs clearly defined results that are
    specific, measurable, achievable, relevant and
    time-bound (SMART)
  • A commonly accepted approach to define project
    objectives is to begin with an object breakdown
    structure (OBS)
  • After the OBS has been compiled, a work breakdown
    structure (WBS) is designed

17
3.3.6 Roles and Responsibilities of Groups and
Individuals
  • Senior management
  • User management
  • Project steering committee

18
3.3.6 Roles and Responsibilities of Groups and
Individuals (continued)
  • Project sponsor
  • Systems development management
  • Project manager
  • Systems development project team

19
3.3.6 Roles and Responsibilities of Groups and
Individuals (continued)
  • User project team
  • Security officer
  • Quality assurance

20
3.4 Project Management Practices
21
3.4.2 Project Planning
  • The project manager needs to determine
  • The various tasks that need to be performed to
    produce the expected business application system
  • The sequence or the order in which these tasks
    need to be performed
  • The duration or the time window for each task
  • The priority of each task
  • The IT resources that are available and required
    to perform these tasks
  • Budget or costing for each of these tasks
  • Source and means of funding

22
3.4.2 Project Planning (continued)
  • Software size estimation
  • Relates to methods of determining the relative
    physical size of the application software to be
    developed
  • Can be used as a guide for the allocation of
    resources, estimates of time and cost required
    for its development, and as a comparison of the
    total effort required by the resources available

23
3.4.2 Project Planning (continued)
  • Lines of source code
  • The traditional and simplest method in measuring
    size by counting the number of lines of source
    code, measured in SLOC, is referred to as kilo
    lines of code (KLOC)

24
3.4.2 Project Planning (continued)
  • Function point analysis
  • Widely used for estimating complexity in
    developing large business applications
  • The results of FPA are a measure of the size of
    an information system based on the number and
    complexity of the inputs, outputs, files,
    interfaces and queries with which a user sees and
    interacts

25
3.4.2 Project Planning (continued)
  • FPA feature points
  • Cost budgets
  • Software cost estimation

26
3.4.2 Project Planning (continued)
  • Scheduling and establishing the time frame
  • Involves establishing the sequential relationship
    among tasks
  • The schedule can be graphically represented using
    various techniques such as Gantt charts or
    Program Evaluation Review Technique (PERT)
    diagram

27
3.4.2 Project Planning (continued)
  • Critical path methodology
  • A critical path if one whose sum of activity time
    is longer than that for any other path through
    the network
  • The critical path is found by working forward
    through the network (forward-pass) and computing
    the earliest possible completion time for each
    activity until the earliest possible completion
    time for the total project is found

28
3.4.2 Project Planning (continued)
  • Gantt charts
  • Constructed to aid in scheduling the activities
    (tasks) needed to complete a project
  • Charts show when an activity should begin and end
  • Charts show which activities can be in progress
    concurrently and which activities must be
    completed sequentially

29
3.4.2 Project Planning (continued)
  • Program evaluation review technique (PERT)
  • PERT is a network management technique often used
    in system development projects based on
    well-defined events and activities for specific
    project management tasks

30
3.4.2 Project Planning (continued)
  • Timebox management
  • Project management technique for defining and
    deploying software deliverables within a
    relatively short and fixed period of time and
    with predetermined specific resources

31
3.4.3 General Project Management
  • Involves automated techniques to handle proposals
    and cost estimations, and to monitor, predict and
    report on performance with recommended action
    items
  • Many of these techniques are provided as decision
    support systems (DSS) for planning and
    controlling project resources

32
3.4.4 Project Controlling
  • Includes management of
  • Scope
  • Resource usage
  • Risk
  • Inventory
  • Assess
  • Mitigate
  • Discover
  • Review evaluate

33
3.4.5 Closing a Project
  • When closing a project, there may still be some
    issues that need to be resolved, ownership of
    which needs to be assigned
  • 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

34
3.5 Business ApplicationDevelopment
  • The implementation process for business
    applications, commonly referred to as an SDLC,
    begins when an individual application is
    initiated as a result of one or more of the
    following situations
  • A new opportunity that relates to a new or
    existing business process
  • A problem that relates to an existing business
    process
  • A new opportunity that will enable the
    organization to take advantage of technology
  • A problem with the current technology

35
3.5 Business Application Development (continued)
  • Benefits of using this approach
  • All affected parties will have a common and clear
    understanding of the objectives and how they
    contribute to business support
  • Conflicting key business drivers (e.g., cost vs.
    functionality) and mutually dependent key
    business drivers can be detected and resolved in
    early stages of an SDLC project

36
3.5 Business ApplicationDevelopment (continued)
  • From an IS auditors perspective, an approach
    with defined life cycles and specific points for
    review provides the following advantages
  • Influence is significantly increased when there
    are formal procedures and guidelines
  • Can review all relevant areas and phases of the
    systems development project and report
    independently to management
  • Can identify selected parts of the system and
    become involved in the technical aspects
  • Can evaluate the methods and techniques applied
    through the development phases

37
3.5.1 Traditional SDLC Approach
  • Also referred to as the waterfall technique, this
    life cycle approach is the oldest and most widely
    used for developing business applications
  • Based on a systematic, sequential approach to
    software development that begins with a
    feasibility study and progresses through
    requirements definition, design, development,
    implementation and postimplementation

38
3.5.1 Traditional SDLC Approach (continued)
  • Some of the problems encountered with this
    approach include
  • Unanticipated events
  • Difficulty in obtaining an explicit set of
    requirements from the user
  • Managing requirements and convincing the user
    about the undue or unwarranted requirements in
    the system functionality
  • The necessity of user patience
  • A changing business environment that alters or
    changes the users requirements before they are
    delivered

39
3.5.2 Integrated Resource Management Systems
  • A growing number of organizations are shifting to
    a fully integrated corporate solution, i.e., an
    ERP solution
  • This type of software implementation is much
    larger than a regular software acquisition
    project
  • ERP systems impact the way a corporation does
    business, its entire control environment,
    technological direction and internal resources

40
3.5.3 Description of Traditional SDLC Phases
  • Feasibility study
  • Concerned with analyzing the benefits and
    solutions for the identified problem area
  • Includes development of a business case, which
    determines the strategic benefits of implementing
    the system either in productivity gains or in
    future cost avoidance
  • Identifies and quantifies the cost savings of the
    new system and estimates a payback schedule for
    the cost incurred in implementing the system or
    shows the projected return on investment (ROI)

41
3.5.3 Description of Traditional SDLC Phases
(continued)
  • Requirements definition
  • Concerned with identifying and specifying the
    business requirements of the system chosen for
    development during the feasibility study
  • Requirements include descriptions of what a
    system should do, how users will interact with a
    system, conditions under which the system will
    operate, and the information criteria the system
    should meet
  • This phase deals with the issues that are
    sometimes called nonfunctional requirements

42
3.5.3 Description of Traditional SDLC Phases
(continued)
  • Entity relationship diagrams
  • An ERD depicts a systems data and how these data
    interrelate
  • An ERD can be used as a requirements analysis
    tool to obtain an understanding of the data a
    system needs to capture and manage
  • An ERD can also be used later in the development
    cycle as a design tool that helps document the
    actual database schema that will be implemented

43
3.5.3 Description of Traditional SDLC Phases
(continued)
  • Software acquisition
  • Not a phase in the standard SDLC. However, if a
    decision was reached to acquire rather than
    develop software, software acquisition is the
    process that should occur after the requirements
    definition phase
  • Decision based on various factors such as the
    cost differential between development and
    acquisition, availability of generic software,
    and the time gap between development and
    acquisition

44
3.5.3 Description of Traditional SDLC Phases
(continued)
  • Software acquisition
  • The project team needs to carefully examine and
    compare the vendors responses to the request for
    proposal (RFP)
  • It is likely that more than one product/vendor
    fits the requirements with advantages and
    disadvantages with respect to each other
  • Once vendors are short listed, it can be
    beneficial for the project team to talk to
    current users of each potential product

45
3.5.3 Description of Traditional SDLC Phases
(continued)
  • Design
  • Key design phase activities include
  • Developing system flowcharts and entity
    relationship models
  • Determining the use of structured design
    techniques
  • End of design phase
  • Describing inputs and outputs
  • Determining processing steps and computation
    rules
  • Determining data file or database system file
    design
  • Preparing program specifications
  • Developing test plans for the various levels of
    testing
  • Developing data conversion plans

46
3.5.3 Description of Traditional SDLC Phases
(continued)
  • Development
  • Key activities performed in a test/development
    environment include
  • Coding and developing program and system-level
    documents
  • Debugging and testing the programs developed
  • Developing programs to convert data from the old
    system for use on the new system
  • Creating user procedures to handle transition to
    the new system
  • Training selected users on the new system
  • Ensure modifications are documented and applied
    accurately

47
3.5.3 Description of Traditional SDLC Phases
(continued)
  • Development
  • Programming methods and techniques
  • Online programming facilities (integrated
    development environment)
  • Programming languages
  • Program debugging
  • Testing

48
Practice Question
  • 3-1 To assist in testing a core banking system
    being acquired, an organization has provided the
    vendor with sensitive data from its existing
    production system. An IS auditors PRIMARY
    concern is that the data should be
  • sanitized.
  • complete.
  • representative.
  • current.

49
3.5.3 Description of Traditional SDLC Phases
(continued)
  • Development
  • Elements of a software testing process
  • Test plan
  • Conduct and report test results
  • Address outstanding issues
  • Testing classifications
  • Unit testing
  • Interface or integration testing
  • System testing
  • Final acceptance testing

50
Practice Question
  • 3-2 Which of the following is the BEST
    preventive measure for reducing the risks of an
    IT system associated with possible natural
    disasters?
  • A. Identify natural threats
  • B. Choose a safe location for the facility
  • C. Keep critical systems separate from general
    systems
  • D. Update and store backups offsite

51
3.5.3 Description of Traditional SDLC Phases
(continued)
  • Development
  • Other types of testing
  • Alpha and beta testing
  • Pilot testing
  • White box testing
  • Black box testing
  • Function/validation testing
  • Regression testing
  • Parallel testing
  • Sociability testing
  • Automated application testing

52
3.5.3 Description of Traditional SDLC Phases
(continued)
  • Implementation
  • During the implementation phase, the actual
    operation of the new information system is
    established and tested
  • Final user-acceptance testing is conducted in
    this environment
  • The system may also go through a certification
    and accreditation process to assess the
    effectiveness of the business application at
    mitigating risks to an appropriate level

53
3.5.3 Description of Traditional SDLC Phases
(continued)
  • Implementation planning
  • Phase 1Develop to-be support structures
  • Phase 2Establish support function
  • End-user training
  • Data migration
  • Refining migration scenario
  • Fallback (rollback) scenario

54
3.5.3 Description of Traditional SDLC Phases
(continued)
  • Changeover (go-live or cutover) techniques
  • Parallel changeover
  • Phased changeover
  • Abrupt changeover
  • Certification/accreditation

55
3.5.3 Description of Traditional SDLC Phases
(continued)
  • A postimplementation review should meet the
    following objectives
  • Assess the adequacy of the system
  • Evaluate the projected cost benefits or ROI
  • Develop recommendations that address the systems
    inadequacies and deficiencies
  • Develop a plan for implementing the
    recommendations
  • Assess the development project process
  • A postimplementation review should be performed
    jointly by the project development team and
    appropriate end users

56
3.5.4 Risks Associated with Software Development
  • Business risk relating to the likelihood that the
    new system may not meet the users business
    needs, requirements and expectations
  • Potential risks that can occur when designing and
    developing software systems
  • Within the project
  • With suppliers
  • Within the organization
  • With the external environment

57
3.5.5 Use of Structured Analysis, Design and
Development Techniques
  • Closely associated with the traditional, classic
    SDLC approach
  • Techniques provide a framework for representing
    the data and process components of an application
    using various graphical notations at different
    levels of abstraction, until it reaches the
    abstraction level that enables programmers to
    code the system

58
3.6.1 Electronic Commerce
  • E-commerce models include the following
  • 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
  • Consumer-to-government (C-to-G) relationships
  • Exchange-to-exchange (X-to-X) relationships

59
3.6.1 Electronic Commerce(continued)
  • With increasing emphasis on integrating the web
    channel with a business internal legacy systems
    and the systems of its business partners, company
    systems now typically will run on different
    platforms, running different software and with
    different databases
  • The challenge of integrating diverse technologies
    within and beyond the business has increasingly
    lead companies to move to component-based systems
    that utilize a middleware infrastructure, based
    around an application server

60
3.6.1 Electronic Commerce (continued)
  • Databases play a key role in most e-commerce
    systems, maintaining data for web site pages,
    accumulating customer information and possibly
    storing click-stream data for analyzing web site
    usage
  • Extensible Markup Language is also likely to form
    an important part of an organizations overall
    e-commerce architecture

61
3.6.1 Electronic Commerce (continued)
  • E-commerce risks
  • Confidentiality
  • Integrity
  • Availability
  • Authentication and nonrepudiation
  • Power shift to customers
  • It is important to take into consideration the
    importance of security issues that extend beyond
    confidentiality objectives

62
3.6.1 Electronic Commerce (continued)
  • An IS auditor should assess applicable use of
  • A set of security mechanisms and procedures that
    constitute a security architecture for e-commerce
  • Firewall mechanisms that are in place to mediate
    between the public network and an organizations
    private network
  • A process whereby participants in an e-commerce
    transaction can be identified uniquely and
    positively
  • Digital signatures
  • An infrastructure to manage and control public
    key pairs and their corresponding certificates
  • The procedures in place to control changes to an
    e-commerce presence

63
3.6.1 Electronic Commerce (continued)
  • An IS auditor should assess applicable use of
  • Logs of e-commerce applications
  • The methods and procedures to recognize security
    breaches when they occur
  • The features in e-commerce applications
  • The protections in place to ensure that data
    collected about individuals are not disclosed
    without their consent
  • The means to ensure confidentiality of data
    communicated between customers and vendors
  • The mechanisms to protect e-commerces presence
    and their supporting private networks from
    computer viruses

64
3.6.1 Electronic Commerce (continued)
  • An IS auditor should assess applicable use of
  • The features within the e-commerce architecture
    to keep all components from failing
  • A plan and procedure to continue e-commerce
    activities in the event of an extended outage of
    required resources for normal processing
  • A commonly understood set of practices and
    procedures to define managements intentions for
    the security of e-commerce
  • A shared responsibility within an organization
    for e-commerce security
  • Communications from vendors to customers
  • A regular program of audit and assessment of the
    security of e-commerce environments and
    applications

65
Practice Question
  • 3-9 When introducing thin client architecture,
    which of the following risks regarding servers
    is significantly increased?
  • Integrity
  • Concurrency
  • Confidentiality
  • Availability

66
3.6.2 Electronic Data Interchange
  • The benefits associated with the adoption of EDI
    include
  • Less paperwork
  • Fewer errors during the exchange of information
  • Improved information flow, database-to-database
    and company-to-company
  • No unnecessary rekeying of data
  • Fewer delays in communication
  • Improved invoicing and payment processes

67
3.6.2 Electronic Data Interchange (continued)
  • General requirements
  • An EDI system requires communications software,
    translation software and access to standards
  • To build a map, an EDI standard appropriate for
    the kind of EDI data to be transmitted is
    selected
  • Final step is to write a partner profile that
    tells the system where to send each transaction
    and how to handle errors and exceptions

68
3.6.2 Electronic Data Interchange (continued)
  • Moving data in a batch transmission process
    through the traditional EDI process generally
    involves three functions within each trading
    partners computer system
  • Communications handler
  • EDI interface
  • EDI translator
  • Application interface
  • Application system

69
3.6.2 Electronic Data Interchange (continued)
  • Web-based EDI has come into prominence due to
  • Internet-through-Internet service providers
    offering generic network access for all computers
    connected to the Internet
  • Its ability to attract new partners via web-based
    sites to exchange information
  • New security products available to address issues
    of confidentiality, authentication, data
    integrity and nonrepudiation of origin and return
  • Improvements in the x.12 EDI formatted standard

70
3.6.4 Controls in EDI Environment
  • To protect EDI transmissions, the EDI process
    should include
  • Standards set to indicate the message format and
    content are valid
  • Controls to ensure standard transmissions are
    properly converted for the application software
    by the translation application
  • Procedures to determine messages are only from
    authorized parties
  • Direct or dedicated transmission channels among
    the parties
  • Data should be encrypted using algorithms agreed
    to by the parties involved

71
3.6.4 Controls in EDI Environment (continued)
  • The EDI process needs the ability to detect and
    deal with transactions that do not conform to the
    standard format or are from/to unauthorized
    parties
  • The critical nature of many EDI transactions
    requires that there be positive assurances that
    the transmissions were complete
  • Organizations desiring to exchange transactions
    using EDI are establishing a new business
    relationship

72
3.6.4 Controls in EDI Environment (continued)
  • The controls for receipt of inbound transactions
    are
  • Use appropriate encryption techniques when using
    public Internet infrastructures for communication
  • Perform edit checks
  • Perform additional computerized checking
  • Log each inbound transaction upon receipt
  • Use control totals on receipt of transactions
  • Segment count totals built into the transaction
    set trailer by the sender
  • Control techniques in the processing of
    individual transactions
  • Ensure the exchange of control totals of
    transactions sent and received between trading
    partners at predefined intervals

73
3.6.4 Controls in EDI Environment (continued)
  • An IS auditor must evaluate EDI to ensure that
    all inbound EDI transactions are received and
    translated accurately, passed to an application
    and processed only once
  • To accomplish this, an IS auditor must review
  • Internet encryption process
  • Edit checks
  • Additional computerized checking
  • Batch control totals
  • The validity of the sender against trading
    partner details

74
Practice Question
  • 3-10 Which of the following procedures should be
    implemented to help ensure the completeness of
    inbound transactions via electronic data
    interchange (EDI)?
  • Segment counts built into the transaction set
    trailer
  • A log of the number of messages received,
    periodically verified with the transaction
    originator
  • An electronic audit trail for accountability and
    tracking
  • Matching acknowledgement transactions received to
    the log of EDI messages sent

75
3.6.5 Electronic Mail
  • At the most basic level, the e-mail process can
    be divided into two principal components
  • Mail servers, which are hosts that deliver,
    forward and store mail
  • Clients, which interface with users and allow
    users to read, compose, send and store e-mail
    messages

76
3.6.5 Electronic Mail (continued)
  • Security issues involved with e-mail include
  • Flaws in the configuration of mail server
    applications
  • Denial-of-service (DoS) attacks may be directed
    to the mail server
  • Sensitive information transmitted unencrypted
    between mail server and e-mail client may be
    intercepted
  • Information within the e-mail may be altered
  • Viruses and other types of malicious code may be
    distributed throughout an organization
  • Users may send inappropriate, proprietary or
    other sensitive information via e-mail

77
3.6.5 Electronic Mail (continued)
  • Digital signatures are a good method of securing
    e-mail transmissions in that
  • The signature cannot be forged
  • The signature is authentic and encrypted
  • The signature cannot be reused
  • The signed document cannot be altered

78
3.6.7 Electronic Banking
  • Banks should have a risk management process to
    enable them to identify, measure, monitor and
    control their technology risk exposure
  • Risk management of new technologies has three
    essential elements
  • Risk management is the responsibility of the
    board of directors and senior management
  • Implementing technology is the responsibility of
    IT senior management members
  • Measuring and monitoring risk is the
    responsibility of members of operational
    management

79
3.6.7 Electronic Banking(continued)
  • E-banking presents a number of risk management
    challenges
  • The speed of change relating to technological and
    service innovation
  • Transactional e-banking web sites and associated
    retail and wholesale business applications are
    typically integrated with legacy computer systems
  • e-Banking increases banks dependence on
    information technology
  • The Internet is ubiquitous and global by nature

80
3.6.7 Electronic Banking(continued)
  • Effective risk management controls for e-banking
    include 14 controls divided among three
    categories
  • Board and management oversight
  • Security controls
  • Legal and reputational risk management

81
3.6.8 Electronic Finance
  • Advantages of e-finance to consumers include
  • Lower costs
  • Increased breadth and quality
  • Widening access to financial services
  • A-synchrony (time-decoupled)
  • A-topy (location-decoupled)

82
3.6.11 Electronic Funds Transfer
  • Electronic funds transfer (EFT) is the exchange
    of money via telecommunications without currency
    actually changing hands
  • Allows parties to move money from one account to
    another, replacing traditional check writing and
    cash collection procedures
  • Usually function via an internal bank transfer
    from one partys account to another or via a
    clearinghouse network

83
3.6.12 Controls in anEFT Environment
  • Security in an EFT environment ensures that
  • All of the equipment and communication linkages
    are tested
  • Each party uses security procedures that are
    reasonably sufficient
  • There are guidelines set for the receipt of data
  • Upon receipt of data, the receiving party will
    immediately transmit an acknowledgment or
    notification
  • Data encryption standards are set
  • Standards for unintelligible transmissions are
    set
  • Regulatory requirements are explicitly stated

84
3.6.15 Automated Teller Machine
  • Recommended internal control guidelines for ATMs
    include
  • Written policies and procedures covering
    personnel, security controls, operations,
    settlement, balancing, etc.
  • Procedures for PIN issuance and protection during
    storage
  • Procedures for the security of PINs during
    delivery
  • Controls over plastic card procurement
  • Controls and audit trails of the transactions
    that have been made in the ATM

85
3.6.20 Artificial Intelligence and Expert Systems
  • Artificial intelligence is the study and
    application of the principles by which
  • Knowledge is acquired and used
  • Goals are generated and achieved
  • Information is communicated
  • Collaboration is achieved
  • Concepts are formed
  • Languages are developed

86
3.6.20 Artificial Intelligence and Expert Systems
(continued)
  • Key to an expert system is the knowledge base
    (KB), which contains specific information or fact
    patterns associated with a particular subject
    matter and the rules for interpreting these facts
  • The information in the KB can be expressed in
    several ways
  • Decision trees
  • Rules
  • Semantic nets

87
3.6.20 Artificial Intelligence and Expert Systems
(continued)
  • An IS auditor should
  • Understand the purpose and functionality of the
    system
  • Assess the systems significance to the
    organization
  • Review the adherence of the system to policies
    and procedures
  • Review procedures for updating information in the
    KB
  • Review security access over the system

88
3.6.21 Business Intelligence
  • Business intelligence (BI) is a broad field of IT
    that encompasses the collection and dissemination
    of information to assist decision making and
    assess organizational performance
  • Some typical areas in which BI is applied
    include
  • Process cost, efficiency and quality
  • Customer satisfaction with product and service
    offerings
  • Customer profitability
  • Staff and business unit achievement of KPIs
  • Risk management

89
3.6.21 Business Intelligence(continued)
  • An optimized enterprise data flow architecture
    consists of
  • Presentation/desktop access layer
  • Data source layer
  • Core data warehouse
  • Data mart layer
  • Data staging and quality layer
  • Data access layer
  • Data preparation layer
  • Metadata repository layer
  • Warehouse management layer
  • Application messaging layer
  • Internet/intranet layer

90
3.6.22 Decision Support System
  • A decision support system (DSS) is an
    interactive system that provides the user with
    easy access to decision models and data from a
    wide range of sources, to support semistructured
    decision-making tasks typically for business
    purposes

91
3.6.22 Decision Support System (continued)
  • A principle of DSS design is to concentrate less
    on efficiency and more on effectiveness
  • A DSS is often developed with a specific decision
    or well-defined class of decisions to solve
  • Frameworks are generalizations about a field that
    help put many specific cases and ideas into
    perspective
  • G. Gorry-M.S. Morton framework
  • Sprague-Carson framework

92
3.6.22 Decision Support System (continued)
  • Prototyping is the most popular approach to DSS
    design and development
  • It is difficult to implement a DSS because of its
    discretionary nature

93
3.6.22 Decision Support System (continued)
  • Developers should be prepared for eight
    implementation risk factors
  • Nonexistent or unwilling users
  • Multiple users or implementers
  • Disappearing users, implementers or maintainers
  • Inability to specify purpose or usage patterns in
    advance
  • Inability to predict and cushion impact on all
    parties
  • Lack or loss of support
  • Lack of experience with similar systems
  • Technical problems and cost-effectiveness issues

94
3.6.22 Decision Support System (continued)
  • The DSS designer and user should use broad
    evaluation criteria, including
  • Traditional cost-benefit analysis
  • Procedural changes, more alternatives examined,
    less time consumer in making the decision
  • Evidence of improvement in decision making
  • Changes in the decision process

95
3.7 Alternative Forms of Software Project
Organization
  • Other approaches an IS auditor may encounter
    include
  • Incremental or progressive development
  • Iterative development
  • Evolutionary development
  • Spiral development
  • Agile development

96
3.7.1 Agile Development
  • Agile development refers to a family of similar
    development processes that espouse a
    nontraditional way of developing complex systems.
  • Agile development processes have a number of
    common characteristics, including
  • The use of small, time-boxed subprojects or
    iterations
  • Replanning the project at the end of each
    iteration
  • Relatively greater reliance on tacit knowledge
  • Heavy influence on mechanisms to effectively
    disseminate tacit knowledge and promote teamwork
  • A change in the role of the project manager

97
3.7.1 Agile Development
98
3.7.2 Prototyping
  • The process of creating a system through
    controlled trial and error procedures to reduce
    the level of risks in developing the system
  • Reduces the time to deploy systems primarily by
    using faster development tools such as
    fourth-generation techniques
  • Potential risk is that the finished system will
    have poor controls
  • Change control often becomes more complicated

99
3.7.3 Rapid ApplicationDevelopment
  • A methodology that enables organizations to
    develop strategically important systems quickly,
    while reducing development costs and maintaining
    quality
  • Achieved through the use of
  • Small, well-trained development teams
  • Evolutionary prototypes
  • Integrated power tools
  • A central repository
  • Interactive requirements and design workshops
  • Rigid limits on development time frames

100
3.8.1 Data-oriented SystemDevelopment
  • A method for representing software requirements
    by focusing on data and their structure
  • Major advantage of this approach is that it
    eliminates data transformation errors such as
    porting, conversion, transcription and
    transposition

101
3.8.2 Object-oriented System Development
  • The process of solution specification and
    modeling where data and procedures can be grouped
    into an entity known as an object
  • OOSD is a programming technique and is not a
    software development methodology itself
  • The major advantages of OOSD are
  • The ability to manage an unrestricted variety of
    data types
  • Provision of a means to model complex
    relationships
  • The capacity to meet the demands of a changing
    environment

102
3.8.3 Component-basedDevelopment
  • Process of assembling applications from
    cooperating packages of executable software that
    make their services available through defined
    interfaces
  • Basic types of components are
  • In-process client components
  • Stand-alone client components
  • Stand-alone server components
  • In-process server components

103
3.8.3 Component-based Development (continued)
  • Components play a significant role in web-based
    applications
  • Component-based development
  • Reduces development time
  • Improves quality
  • Allows developers to focus more strongly on
    business functionality
  • Promotes modularity
  • Simplifies reuse
  • Reduces development cost
  • Supports multiple development environments

104
3.8.4 Web-based Application Development
  • Designed to achieve easier and more effective
    integration of code modules within and between
    enterprises
  • Different from traditional third- or
    fourth-generation program developments in many
    ways
  • Languages and programming techniques used
  • Methodologies used to control development work
  • The way users test and approve development work

105
3.8.6 Reverse Engineering
  • The 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
  • Major advantages
  • Faster development and reduced SDLC duration
  • Possibility of introducing improvements by
    overcoming the reverse-engineered application
    drawbacks

106
3.9 Infrastructure Development/Acquisition
Practices
  • The physical architecture analysis, the
    definition of a new one and the necessary road
    map to move from one to the other are critical
    tasks for an IT department
  • Goals
  • To successfully analyze the existing architecture
  • To design a new architecture
  • To write the functional requirements of this new
    architecture
  • To develop a proof of concept

107
3.9 Infrastructure Development/Acquisition
Practices (continued)
  • Physical implementation of the required technical
    infrastructure to set up the future environment
    will be planned next
  • Task will cover procurement activities such as
    contracting partners, setting up the SLAs, and
    developing installation plans and installation
    test plans

108
3.9.1 Project Phases of Physical Architecture
Analysis
109
3.9.2 Planning Implementation of Infrastructure
  • To ensure the quality of results, a phased
    approach is necessary
  • Communication processes should be set up to other
    projects
  • Through these different phases the components are
    fit together, and a clear understanding of the
    available and contactable vendors is established
    by using the selection process during the
    procurement phase and beyond

110
3.9.2 Planning Implementation of Infrastructure
(continued)
111
3.9.2 Planning Implementation of Infrastructure
(continued)
112
3.9.2 Planning Implementation of Infrastructure
(continued)
113
3.9.2 Planning Implementation of Infrastructure
(continued)
114
3.9.2 Planning Implementation of Infrastructure
(continued)
115
3.9.4 Hardware Acquisition
  • For acquiring a system, the invitation to tender
    (ITT) should include the following
  • Organizational descriptions
  • Information processing requirements
  • Hardware requirements
  • System software applications
  • Support requirements
  • Adaptability requirements
  • Constraints
  • Conversion requirements

116
3.9.4 Hardware Acquisition(continued)
  • Acquisition steps include, but are not limited
    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 vendors financial condition
  • Analysis of the vendors capability to provide
    maintenance and support (including training)

117
3.9.4 Hardware Acquisition(continued)
  • Acquisition steps include, but are not limited
    to, the following
  • Review of delivery schedules against requirements
  • 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

118
3.9.5 System Software Acquisition
  • When selecting new system software, the following
    technical issues should be considered
  • Business, functional, technical needs and
    specifications
  • Cost and benefits
  • Obsolescence
  • Compatibility with existing systems
  • Security
  • Demands on existing staff
  • Training and hiring requirements
  • Future growth needs
  • Impact on system and network performance

119
3.9.7 System Software Change Control Procedures
  • All test results should be documented, reviewed
    and approved by technically-qualified subject
    matter experts prior to production use
  • Change control procedures are designed to ensure
    that changes are authorized and do not disrupt
    processing

120
3.10.1 Change ManagementProcess Overview
  • Change management process begins with authorizing
    changes to occur
  • Requests initiated from end users, operational
    staff and system development/maintenance staff
  • Change requests should be in a format that
    ensures all changes are considered for action and
    that allows the system management staff to easily
    track the status of the request
  • All requests for changes should be maintained by
    the system maintenance staff as part of the
    systems permanent documentation

121
3.10.1 Change Management Process Overview
(continued)
  • Deploying changes
  • Documentation
  • Testing changed programs
  • Auditing program changes
  • Emergency changes
  • Deploying changes back into production
  • Change exposures (unauthorized changes)

122
3.10.2 Configuration Management
  • Maintenance requests must be formally documented
    and approved by a change control group
  • Careful control is exercised over each stage of
    the maintenance process via checkpoints, reviews
    and sign-off procedures
  • From an audit perspective, provides evidence of
    managements commitment to careful control
  • Involves procedures throughout the software life
    cycle

123
3.10.2 Configuration Management (continued)
  • As part of the software configuration management
    task, the maintainer performs the following
    tasks
  • 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
  • Develop release procedures
  • Perform configuration control activities
  • Update the configuration status accounting
    database

124
3.11.2 Computer-aided Software Engineering
  • CASE is the use of automated tools to aid in the
    software development process
  • May include the application of software tools for
    software requirements analysis, software design,
    code production, testing, document generation and
    other software development activities
  • Three categories
  • Upper CASE
  • Middle CASE
  • Lower CASE

125
3.11.2 Computer-aided Software Engineering
(continued)
  • Key issues an IS auditor needs to consider with
    CASE include
  • CASE tools do not ensure that the design,
    programs and system are correct or that they
    fully meet the needs of the organization
  • CASE tools should complement and fit into the
    application development methodology
  • The integrity of data moved between CASE products
    needs to be monitored and controlled
  • Changes to the application should be reflected in
    stored CASE product data

126
3.11.3 Fourth-generation Languages
  • Common characteristics of 4GLs include
  • Nonprocedural language
  • Environmental independence (portability)
  • Software facilities
  • Programmer workbench concepts
  • Simple language subsets
  • 4GLs are classified as
  • Query and report generators
  • Embedded database 4GLs
  • Relational database 4GLs
  • Application generators

127
3.12.1 Business Process Reengineering and Process
Change Projects
  • The steps in a successful BPR are
  • Define the areas to be reviewed
  • 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

128
3.12.1 Business Process Reengineering and Process
Change Projects
129
3.12.1 Business Process Reengineering and Process
Change Projects (continued)
  • A successful BPR/process change project requires
    the project team to perform the following for the
    existing processes
  • Process decomposition to the lowest level
    required for effectively assessing a business
    process
  • Identification of customers, process-based
    managers or process owners responsible for
    beginning to end processes
  • Documentation of the elementary process-related
    profile information

130
3.12.1 Business Process Reengineering and Process
Change Projects (continued)
  • BPR methods and techniques
  • Benchmarking process
  • Plan
  • Research
  • Observe
  • Analyze
  • Adapt
  • Improve

131
Practice Question
  • 3-3 When conducting a review of business
    process reengineering, an IS auditor found that
    a key preventive control had been removed. In
    this case, the IS auditor should
  • inform management of the finding and determine
    whether management is willing to accept the
    potential material risk of not having that
    preventive control.
  • determine if a detective control has replaced the
    preventive control during the process and, if it
    has not, report the removal of the preventive
    control.
  • recommend that this and all control procedures
    that existed before the process was reengineered
    be included in the new process.
  • develop a continuous audit approach to monitor
    the effects of the removal of the preventive
    control.

132
Practice Question
  • 3-4 During which of the following steps in the
    business process reengineering should the
    benchmarking team visit the benchmarking
    partner?
  • Observation
  • Planning
  • Analysis
  • Adaptation

133
3.13 Application Controls
  • Application controls are 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

134
3.13 Application Controls (continued)
  • An IS auditors tasks include the following
  • Identifying the significant application
    components and the flow of transactions through
    the system
  • Identifying the application control strengths
  • Testing the controls to ensure their
    functionality and effectiveness
  • Evaluating the control environment
  • Considering the operational aspects of the
    application to ensure its efficiency and
    effectiveness

135
3.13.1 Input/Origination Controls
  • Input authorization
  • Input authorization verifies that all
    transactions have been authorized and approved by
    management
  • Types of authorization include
  • Signatures on batch forms or source documents
  • Online access controls
  • Unique passwords
  • Terminal or client workstation identification
  • Source documents

136
3.13.1 Input/Origination Controls (continued)
  • Batch controls and balancing
  • Batch controls group input transactions to
    provide control totals
  • Types of batch controls include
  • Total monetary amount
  • Total items
  • Total documents
  • Hash totals

137
3.13.1 Input/Origination Controls (continued)
  • Batch controls and balancing
  • Batch balancing can be performed through manual
    or automated reconciliation
  • Types of batch balancing include
  • Batch registers
  • Control accounts
  • Computer agreement

138
3.13.1 Input/Origination Controls (continued)
  • Error reporting and handling
  • Input processing requires that controls be
    identified to verify that data are accepted into
    the system correctly and that input errors are
    recognized and corrected
  • Input error handling can be processed by
  • Rejecting only transactions with errors
  • Rejecting the whole batch of transactions
  • Holding the batch in suspense
  • Accepting
About PowerShow.com