Chap3 2007 Cisa Review Course

200 7 CISA ® Review Course Chapter 3 Systems and Infrastructure Life Cycle Management

Process Area Overview . . . Business Realization Project Management Structure Project Management Practices Business Application Development Alternative Application Development Approaches Infrastructure Development / Acquisition Practices Information Systems Maintenance Practices System Development Tools and Productivity Aids

. . . Process Area Overview Process Improvement Practices Application Controls Auditing Application Controls Auditing Systems Development, Acquisition and Maintenance Business Application Systems

Process Area Objective Ensure that the CISA candidate… Understands and can provide assurance that the management practices for the development/acquisition, testing, implementation, maintenance, and disposal of systems and infrastructure will meet the organization’s objectives.

Process Area Summary According to the CISA Certification Board, this Process Area will represent approximately 16% of the CISA examination (approximately 32 questions).

3.1 BUSINESS REALIZATION Portfolio/Program Management A program can be seen as a group of projects and time- bound tasks that are closely linked together through common objectives, a common budget, intertwined schedules and strategies. Like projects, programs have a limited time frame (start and end date) and organizational boundaries.

Program scope, program financials (costs, resources cash-flow, etc.), program schedules, and program objectives and deliverables Program context and environment Program communication and culture Program organization 3.1 BUSINESS REALIZATION Portfolio/Program Management

The objectives of project portfolio management are: • Optimization of the results of the project portfolio (not of the individual projects) • Prioritizing and scheduling projects • Resource coordination (internal and external) • Knowledge transfer throughout the projects 3.1 BUSINESS REALIZATION Portfolio/Program Management

An important consideration in any IT project, whether it be the development of a new system or the investment in new infrastructure, is the business case. It has been increasingly recognized that the achievement of business benefits should drive projects. 3.1.2 Business Case Development and Approval: 3.1 BUSINESS REALIZATION Portfolio/Program Management

This concept is called benefits management or benefits realization. It 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 3.1.3. Benefit realization techniques : 3.1 BUSINESS REALIZATION Portfolio/Program Management

3.2 PROJECT MANAGEMENT STRUCTURE Today, many approaches to project management exist. Some are focused on software development, others have a more general approach; some concentrate on a holistic and systemic view, others provide a very detailed workflow including templates for document creation.

3.2 PROJECT MANAGEMENT STRUCTURE 3.2.1 General Aspects : A project is normally a one-time effort. It can be complex; involves an element of risk, with a specific objective, deliverable, and start and end dates; and is divisible into explicit phases

3.2 PROJECT MANAGEMENT STRUCTURE 3.2.2 Project Context and Environment : • Importance of the project in the organization • Connection between the organization’s strategy and the project • Relationship between the project and other projects • Connection between the project to the underlying business case

3.2 PROJECT MANAGEMENT STRUCTURE 3.2.3 Project Organizational Forms : Three major forms of organizational alignment for project management can be observed: • Influence project organization • Pure project organization • Matrix project organization

3.2 PROJECT MANAGEMENT STRUCTURE 3.2.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 thereof

3.2 PROJECT MANAGEMENT STRUCTURE 3.2.5 Project Objectives : A project needs clearly defined results that are specific, measurable, achievable, relevant and time bound (SMART). A holistic project view ensures the consideration and consolidation of all closely coupled objectives. These objectives are broken down into main objectives, additional objectives and nonobjectives.

3.2 PROJECT MANAGEMENT STRUCTURE 3.2.6 Roles and Responsibilities of groups and individuals : To achieve a successful completion and implementation of any new system, it is advisable that the audit function has an active part, where appropriate, in the life cycle development of the business application. This will facilitate efforts to ensure that proper controls are designed and implemented in the new system.

3.2 PROJECT MANAGEMENT STRUCTURE 3.2.6 Roles and Responsibilities of groups and individuals : The various roles and responsibilities of groups/individuals that may be involved in the development process are summarized as follows: Senior Management User Management Project Steering Committee Project Sponsor Systems Development Management Project Manager . . .

3.2 PROJECT MANAGEMENT STRUCTURE 3.2.6 Roles and Responsibilities of groups and individuals : Systems Development Project Team User Project Team Security Officer Quality Assurance

3.3 PROJECT MANAGEMENT PRACTICES Project management is the application of knowledge, skills, tools and techniques applied to a broad range of activities to achieve a stated objective, such as meeting the defined user requirements and deadlines for an IS project.

3.3 PROJECT MANAGEMENT PRACTICES There are three elements or dimensions of a project that should always be taken into account: • Time/duration — How long will it take to complete the project? • Cost/resources — How much will it cost? • Deliverables — What has to be done?

3.3 PROJECT MANAGEMENT PRACTICES A project will be initiated by a project manager or sponsor gathering the information required to gain approval for the project to be created. This will often be compiled into a terms of reference or project charter that states the objective of the project, the stakeholders in the system to be produced, and the project manager and sponsor. Approval of a project initiation document (PID) or a project request document (PRD) is the authority for a project to begin. 3.3.1 Initiation of a project :

3.3 PROJECT MANAGEMENT PRACTICES 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 3.3.2 Project Planning :

3.3 PROJECT MANAGEMENT PRACTICES Software size estimation relates to methods of determining the relative physical size of the application software to be developed. It can be used as a guide to the allocation of resources, estimates of time and cost required for its development, and as a comparison of the total effort required to the resources available. Software Size Estimation:

3.3 PROJECT MANAGEMENT PRACTICES 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). An alternative but similar metric is thousand delivered source instructions (KDSI). This method has proved to be superior when using structured programming languages, such as BASIC or COBOL. Lines of Source Code:

3.3 PROJECT MANAGEMENT PRACTICES Function Point Analysis: The function point analysis (FPA) technique was developed in the late 1970s and has become widely used for estimating complexity in developing large business applications.

3.3 PROJECT MANAGEMENT PRACTICES FPA Feature Points: In most standard applications, lists of functions are identified and the corresponding effort is estimated. In web-enabled applications, the development effort depends on the number of screens (forms), number of images, type of images (static or animated), features to be enabled, interfaces and cross referencing that is required.

3.3 PROJECT MANAGEMENT PRACTICES Cost Budgets: The estimates for each task should contain some or all of the following elements: • Personnel hours by type (e.g., system analyst, programmer, clerical) • Machine hours (predominantly computer time as well as duplication facilities, office equipment and communication equipment) • Other external costs, such as third-party software, licensing of tools for the project, consultant or contractor fees, training costs, certification costs (if required) and occupation costs (if extra space is required for the project).

3.3 PROJECT MANAGEMENT PRACTICES Software Cost Estimation Cost estimation is a consequence of software size estimation. This is a necessary step in properly scoping to adequately scope a project. There are automated techniques for cost estimation of projects at each phase of system development.

Software Cost Estimation 3.3 PROJECT MANAGEMENT PRACTICES To use these products, a system is usually divided into main components, and a set of cost drivers is established. Components include: • Source code language • Execution time constraints • Main storage constraints • Data storage constraints • Computer access • The target machine used for development • The security environment • Staff experience

Scheduling and Establishing the Time Frame: 3.3 PROJECT MANAGEMENT PRACTICES This is achieved by arranging tasks according to: • Earliest start date, by considering the logical sequential relationship among tasks and attempting to perform tasks in parallel wherever possible • Latest expected finish date, by considering the estimate of hours per the budget and the expected availability of personnel or other resources and allowing for known, elapsed-time considerations (holidays, recruitment time, full-time/part-time employees)

Critical Path Methodology 3.3 PROJECT MANAGEMENT PRACTICES All project management techniques compute what is called a critical path. Since a project consists of an ordered set of independent activities, it can be represented as a network where activities are shown as branches connected at nodes immediately preceding and immediately following activities.

Gantt Charts: 3.3 PROJECT MANAGEMENT PRACTICES Gantt charts can be constructed to aid in scheduling the activities (tasks) needed to complete a project. The charts show when an activity should begin and when it should end.

3.3 PROJECT MANAGEMENT PRACTICES Program Evaluation Review Technique : The Program Evaluation Review Technique (PERT) is a network management technique often used in system development projects based on well-defined events and activities for specific project management tasks.

3.3 PROJECT MANAGEMENT PRACTICES Timebox Management : Timebox management is another project management technique for defining and deploying software deliverables within a relatively short and fixed period of time and with predetermined specific resources.

3.3 3 GENERAL PROJECT MANAGEMENT Documentation : Automated documentation tools to handle the production, validation and maintenance of system and program documentation. These tools often allow the user to input program and system parameters without having to learn high-powered word processing functions. The package then generates program narratives and flowcharts from the input provided by the user.

3.3 3 GENERAL PROJECT MANAGEMENT Office Automation : Office automation reduces programmer involvement in functions that are required to comply with policies and staff meetings. Types of office automation tools that have proven to be useful and productive are electronic mail systems, voice-messaging systems, automated time management tools (such as electronic calendars and date reminders), automated libraries, and filing and retrieval systems.

3.3.4 PROJECT CONTROLLING The controlling activities of a project include management of scope, resource usage and risk. It is important that new requirements for the project are documented and, if approved, allocated appropriate resources. Control of change during a project ensures that projects are completed within stakeholders’ expectations of time, use of funds and quality objectives.

3.3.5 CLOSING A PROJECT A project should have a finite life, so at some point it is closed and the new or modified system is handed over to the users and/or system support staff. At this point, 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.

3.4 BUSINESS APPLICATION DEVELOPMENT Companies often commit significant information technology resources (e.g., people, applications, facilities, technology) to develop, acquire and maintain application systems that are critical to the effective functioning of key business processes. These systems, in turn, often control critical information assets and should be considered an asset that needs to be effectively managed and controlled.

3.4 BUSINESS APPLICATION DEVELOPMENT 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

3.4 BUSINESS APPLICATION DEVELOPMENT From an IS auditor’s perspective, such an approach, with defined life cycle phases and specific points for review and evaluation, provides the following advantages: • The IS auditor’s influence is significantly increased when there are formal procedures and guidelines identifying each phase in the business application life cycle and the extent of auditor involvement. • The IS auditor can review all relevant areas and phases of the systems development project and report independently to management on the adherence to planned objectives and company procedures.

3.4 BUSINESS APPLICATION DEVELOPMENT • The IS auditor can identify selected parts of the system and become involved in the technical aspects on the basis of their skills and abilities. • The IS auditor can provide an evaluation of the methods and techniques applied through the development phases of the business application life cycle.

3.4 BUSINESS APPLICATION DEVELOPMENT 3.4.1 THE TRADIONAL SYSTEM DEVELOPMENT LIFE CYCLE APPROACH: Over the years, business application development has occurred largely through the use of the traditional SDLC phases. Also referred to as the waterfall technique, this life cycle approach is the oldest and most widely used for developing business applications.

3.4 BUSINESS APPLICATION DEVELOPMENT 3.4.1THE TRADITIONAL SYSTEM DEVELOPMENT LIFE CYCLE APPROACH: SDLC PHASE: Feasibility Requirements Design Selection Development Configuration Implementation Post Implementation

3.4 BUSINESS APPLICATION DEVELOPMENT 3.4.2 INTEGRATED RESOURCE MANAGEMENT SYSTEMS: A growing number of organizations—public and private—are shifting from separate groups of interrelated applications to a fully integrated corporate solution. Such solutions are often marketed as enterprise resource planning (ERP) solutions. Many vendors, mainly from Europe and the US, have been focusing on this market and offer packages with commercial names, such as SAP, PeopleSoft, Oracle Financials, SSG (Baan) or J.D. Edwards.

3.4 BUSINESS APPLICATION DEVELOPMENT 3.4.3 DESCRIPTION OF TRADITIONAL SLDC PHASES FEASIBILITY STUDY Once the determination has been made to move forward with a project, an analysis begins to clearly define the need and to identify alternatives for addressing the need. This analysis is known as the feasibility study.

3.4 BUSINESS APPLICATION DEVELOPMENT REQUIREMENTS DEFINITION Requirements definition is 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. CobiT’s framework principles for information criteria show that this includes issues associated with effectiveness, efficiency, confidentiality, integrity, availability, compliance and reliability.

3.4 BUSINESS APPLICATION DEVELOPMENT ENTITY RELATIONSHIP DIAGRAMS An ERD depicts a system’s 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. In this case, the ERD represents a logical data model. 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. Used in this way, the ERD represents a physical data model.

3.4 BUSINESS APPLICATION DEVELOPMENT SOFTWARE ACQUISITION Software acquisition is not a phase in the standard SDLC. However, if a decision was reached to acquire rather than develop software, is the process that should occur after the requirements definition phase. The feasibility study should contain documentation that supports the decision to acquire the software. 1. Software is required for a generic business process for which vendors are available and software can be implemented as-is. 2. Vendor’s software needs to be customized to suit business processes. 3. Software needs to be developed by the vendor.

An organization decides to purchase a package instead of developing it. In such a case, the design and development phases of a traditional software development life cycle (SDLC) would be replaced with: A. selection and configuration phases. B. feasibility and requirements phases. C. implementation and testing phases. D. nothing; replacement is not required. Chapter 3 Question 6

3.4 BUSINESS APPLICATION DEVELOPMENT RFP CONTENTS Product vs. Systems Requirements Customer References Vendor viability / financial stability Availability of complete and reliable documentation Vendor Support Source code availability Number of years experience in offering the product A list of recent or planned enhacements to the product, with dates Number of client sites using the product with a list of current users Acceptance testing of the product

3.4 BUSINESS APPLICATION DEVELOPMENT DESIGN Based on the general preliminary design and user requirements defined in the requirements definition phase, a detailed design can be developed. Once business processes have been documented and it is understood how those processes might be executed in the new system, involvement of users during the design phase is limited.

3.4 BUSINESS APPLICATION DEVELOPMENT DEVELOPMENT . . . Key activities performed in a test/development environment include: • Coding and developing program and system-level documents • Debugging and testing 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 since their participation will be needed • Ensuring modifications are documented and applied accurately and completely to vendor-acquired software to ensure that future updated versions of the vendor’s code can be applied

Chapter 3 Question 4 User specifications for a project using the traditional SDLC methodology have 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

3.4 BUSINESS APPLICATION DEVELOPMENT . . . DEVELOPMENT IT’S NECESSARY TO CONSIDER: Programming methods and techniques. Online Programming facilities. Programming languages. Programming Debugging. Testing. Elements of a software testing process. Testing classification. Other types of testing. Automated application testing.

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 auditor’s PRIMARY concern is that the data should be: A. sanitized. B. complete. C. representative. D. current. Chapter 3 Question 3

3.4 BUSINESS APPLICATION DEVELOPMENT 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.

3.4 BUSINESS APPLICATION DEVELOPMENT IMPLEMENTATION PLANNING Once developed and ready for operation, the new system delivered by the project will need an efficient support structure. It is not enough to just set up a support structure defining some roles and naming some people to fulfill these roles. These people will need to acquire new skills.

3.4 BUSINESS APPLICATION DEVELOPMENT IMPLEMENTATION PLANNING The main goals are to: • Provide appropriate support structures for first- second- and third- line support teams • Provide a single point of contact (SPOC) • Provide roles and skills definitions with applicable training plans

3.4 BUSINESS APPLICATION DEVELOPMENT IMPLEMENTATION PLANNING To achieve significant improvement of the situation, it is necessary to address some important questions such as: • How can the existing support staff be involved in the setup of the new project without neglecting the currently running system? • What is the gap of “know-how” that must be addressed in the training plan? • How big is the difference from the current legacy environment operation to the operation of the new platform?

3.4 BUSINESS APPLICATION DEVELOPMENT IMPLEMENTATION PLANNING Such a project shall include the following requirements and expectations: • There should be a smooth transition from the existing platform to the new platform without any negative effect on users of the system. • There should be maximum employment of the existing support staff to operate the new system environment and keep the effort of new hires at a minimum level.

3.4 BUSINESS APPLICATION DEVELOPMENT Phase 1- Develop To-Be Support Structures - Gap Analysis One possible approach to determine the gap—the differences between the current support organization and the future one—is to schedule workshops with the appropriate staff members who are dealing with system operational tasks or support processes at present. This shall also include representatives of the current helpdesk unit.

3.4 BUSINESS APPLICATION DEVELOPMENT Phase 1- Develop To-Be Support Structures - Role Definitions The main objectives of an operations manager are: • Motivate and develop the operational staff under their control to ensure that all information and communication technologies (ICT) services meet their SLA targets, within the agreed financial budget; ensure that these staffs have up-to-date job descriptions, are regularly appraised and have a current training plan for personal development; arrange for the recruitment of staff as necessary.

3.4 BUSINESS APPLICATION DEVELOPMENT Phase 1- Develop To-Be Support Structures - Role Definitions • Develop and maintain controls and procedures to ensure that the operational processes run efficiently and that, in the event of failure, operations can recover services, in accordance with a predefined and tested recovery or continuity plan, to agreed fallback levels of service within the agreed targeted recovery time. • Ensure that the physical environment is maintained and secure, according to contractual requirements and business needs. • Ensure that any new ICT infrastructure meets the agreed operability and manageability criteria for live running prior to accepting them for operational use.

3.4 BUSINESS APPLICATION DEVELOPMENT Phase 1- Develop To-Be Support Structures - Role Definitions • Plan and oversee the installation of ICT infrastructure and liaise regularly with vendor staff to ensure adequate support is provided. • Ensure that all operational management reports and information are produced in a timely fashion for all other ICT, service and business management processes. • Ensure that all contractual documentation relevant to maintenance contracts is complete. • Ensure that operational processes are continually developed and improved. • Ensure that all operational staff is aware of and comply with all operational, ICT and service management processes.

3.4 BUSINESS APPLICATION DEVELOPMENT Phase 1- Develop To-Be Support Structures - Role Definitions The main responsibilities of the operation manager are: • Be the owner of all of the ICT operations processes. • Manage operational activities on a day-to-day shift basis, ensuring that all agreed operational targets are met. • Direct operations staff to run the ICT production cycle in line with the controls and processes established to meet production deadlines and ensure that there is an effective handover with other shifts—to maintain the level of ICT services across shift boundaries.

3.4 BUSINESS APPLICATION DEVELOPMENT Phase 1- Develop To-Be Support Structures - Role Definitions • Develop, maintain and enforce acceptance criteria and procedures for the implementation of new ICT infrastructure into the operational environment. • Ensure that all operational ICT infrastructures are operated in accordance with security, environmental and all other organizational policies. • Ensure, with problem management/specialist support/vendor assistance as required. • Provide regular feedback on operational performance to ICT management, recommending any improvements required.

3.4 BUSINESS APPLICATION DEVELOPMENT Phase 1- Develop To-Be Support Structures - Role Definitions • Handle all exceptions within scope and escalate, where necessary, those matters beyond the appropriate level of authority. • Ensure that ICT infrastructure, environmental housekeeping procedures and system backups are performed to the prescribed standard. • Look after operations personnel matters, including staff development, training, education, performance reviews, appraisals, disciplinary issues and counseling .

3.4 BUSINESS APPLICATION DEVELOPMENT Phase 1- Develop To-Be Support Structures - Role Definitions • Train operations staff in new services, applications and equipment, and arrange and run any necessary training, ensuring that appropriate operational documentation is produced. • Check the completion of acceptance criteria for all new and changed services. • Be responsible for quality assurance, validation and acceptance of all ICT infrastructure component deliveries. • Ensure that all third-party personnel are appropriately supervised within all ICT operational environments.

3.4 BUSINESS APPLICATION DEVELOPMENT Phase 1- Develop To-Be Support Structures - Role Definitions • Manage the operational budget ensuring that actual expenditure is within the forecasted level. • Regularly review ICT operational processes for efficiency, effectiveness and compliance with a view to instigating a continuous process of improvement within all ICT operational areas. • Manage the operational budget ensuring that actual expenditure is within the forecasted level. • Regularly review ICT operational processes for efficiency, effectiveness and compliance with a view to instigating a continuous process of improvement within all ICT operational areas.

3.4 BUSINESS APPLICATION DEVELOPMENT Phase 2- Establish Support Functions - Service Level Agreement The SLA shall at least consider the following items: • Operating time • Support time • Mean time between failures (MTBF) • Mean time to repair (MTTR) • Response time (technical)

3.4 BUSINESS APPLICATION DEVELOPMENT Phase 2- Establish Support Functions - Implementation Plan / Knowledge Transfer Plan Due to best practices the transfer should follow the shadowing and relay-baton method. This approach is the best suitable concept to transfer knowledge, but also to transfer responsibility in a transparent way. The metaphor of the “relay-baton” expresses exactly what must be achieved.

3.4 BUSINESS APPLICATION DEVELOPMENT Phase 2- Establish Support Functions - Training Plans The training plans for the staff shall show all of the required trainings in terms of: • Content • Scheduling information • Duration • Delivery Mechanism (Classroom and/or web-based) • The train-the-trainer concept

3.4 BUSINESS APPLICATION DEVELOPMENT Phase 2- Establish Support Functions - Training Plans The following list gives an impression about work tasks defined to fulfill the overall project goal: • Collate existing support structure documentation. • Review existing IT organization model. • Define the new support organization structure. • Define the new support processes. • Map the new process to the organization model. • Execute the new organization model. • Establish support functions.

3.4 BUSINESS APPLICATION DEVELOPMENT Phase 2- Establish Support Functions - Training Plans • Develop communications material for support staff. • Conduct briefing and training sessions. • Review mobilization progress. • Transfer to new organization structure. • Review of items above.

3.4 BUSINESS APPLICATION DEVELOPMENT End – User Training To create the training strategy, the organization must name a training administrator who should identify users who need to be trained with respect to their specific job functions. Consideration should be given to the following format and delivery mechanisms: • Case studies • Role-based training • Lecture and breakout sessions • Modules at different experience levels • Practical sessions on how to use the system

3.4 BUSINESS APPLICATION DEVELOPMENT End – User Training • Remedial computer training (if needed) • Online sessions on the web or on a CD-ROM

3.4 BUSINESS APPLICATION DEVELOPMENT Data Conversion A data conversion exercise is done when a new system is being implemented to replace an existing system for reasons such as a software upgrade or the installation and implementation of a new system.

3.4 BUSINESS APPLICATION DEVELOPMENT Data Conversion Another important goal set is to minimize risk. • Minimize risks • Minimize disturbances on daily work • Segment, migrate and progressively put into service applications and data • Handle security and confidentiality • Manage the coexistence of legacy and migrated operations • Ensure data consistency and integrity during the migration

3.4 BUSINESS APPLICATION DEVELOPMENT Data Conversion – Refining Migration Scenario Module analysis has to be completed to scope the implementation projects regarding functional modules and data entities. Based on this information and analyzing the business requirements, the implementation project’s plan will be refined.

3.4 BUSINESS APPLICATION DEVELOPMENT Data Conversion – Refining Migration Scenario • Support migration process —To administrate the enterprise repository during the project, a support process has to be designed and set up. Due to the recommendation that this repository will be used upon completion of the project to manage the software components of the new architecture, this process has to be conforming to development processes. The enterprise repository administration and report generation supports the migration by mainly reverse-engineering the changes in the legacy architecture and running impact analysis reports.

3.4 BUSINESS APPLICATION DEVELOPMENT Data Conversion – Refining Migration Scenario • Migration infrastructure —The project team has to cover the specification of the migration infrastructure in the migration project. This approach ensures the consistency of the architecture and gives the ability to guarantee the functionality of the fallback scenario. To do this, the migration project will complete a high-level analysis of the legacy and new data model to establish links between them, which will be refined later.

3.4 BUSINESS APPLICATION DEVELOPMENT Data Conversion – Fall Back(Rollback) Scenario Best practices appreciate the approach of the staged deployment of applications to mitigate the risk on the mission-critical applications. For this reason, components to reverse the data conversion are needed.

3.4 BUSINESS APPLICATION DEVELOPMENT Data Conversion – Fall Back Scenario The key points to be taken into consideration in a data conversion project are to ensure: Completeness of data conversion Integrity of data Confidentiality Consistency of data Continuity That a latest copy of the data before conversion from the old platform and the first copy of the data after conversion on the new platform should be maintained separately in the archival for any reference in future

3.4 BUSINESS APPLICATION DEVELOPMENT Cutover (Go Live) Techniques Changeover refers to an approach to shift users from using application from the existing (old) system to the replacing (new) system. This is possible only after testing the new system with respect to its program and relevant data. This is sometimes called the go-live technique as it enables the start of the new system. This approach is also called the cutover technique as it helps in cutting out from the older system and moving over to the newer system.

3.4 BUSINESS APPLICATION DEVELOPMENT Cutover (Go Live) Techniques Parallel changeover: This technique includes, along the time line, running the old system, then running both the old and new systems in parallel, and finally changing over to the new system fully after gaining confidence on the working of the new system. In this approach, the users will have to use both systems during the period of overlap.

3.4 BUSINESS APPLICATION DEVELOPMENT Cutover (Go Live) Techniques Phased Changeover: In this approach, the older system is broken into deliverable modules. Initially, the first module of the older system is phased out using the first module of the newer system. Then, the second module of the older system is phased out, using the second module of the newer system and so forth until reaching the last module. Thus, the changeover from the older system to the newer system takes place in a preplanned, phased manner.

3.4 BUSINESS APPLICATION DEVELOPMENT Cutover (Go Live) Techniques Abrupt Changeover: In this approach, the newer system is changed over from the older system on a cutoff date and time and the older system is discontinued once changeover to the new system takes place.

3.4 BUSINESS APPLICATION DEVELOPMENT Certification / Accreditation Certification is the process by which an assessor organization, through their empanelled assessors or auditors, examines the level of compliance of an organization in meeting certain requirements, such as standards, policies, processes, procedures, work instructions and guidelines. The end product of the certification process is the presentation of a certificate defining the scope of assessment, which includes location, process, resources, etc., and attesting that the assessed organization is compliant with the certification standards.

3.4 BUSINESS APPLICATION DEVELOPMENT Postimplementation Review Following the successful implementation of a new or extensively modified system, it is beneficial to verify that the system has been properly designed and developed and that proper controls have been built into the system.

3.4 BUSINESS APPLICATION DEVELOPMENT Post Implementation Review As such, a postimplementation review should meet the following objectives: • Assess the adequacy of the system: – Does the system meet user requirements and management’s objectives? – Have access controls been adequately defined and implemented? • Evaluate the projected cost benefits or (ROI) measurements.

• Develop recommendations that address the system’s inadequacies and deficiencies. • Develop a plan for implementing the recommendations. • Assess the development project process: – Were the chosen methodologies, standards and techniques followed? – Were appropriate project management techniques used? 3.4 BUSINESS APPLICATION DEVELOPMENT Post Implementation Review

3.4 BUSINESS APPLICATION DEVELOPMENT Post Implementation Review It is important to note that for a postimplementation review to be effective, the information to be reviewed should be identified during the project startup phase, and collected during each stage of the project. For instance, the project manager might establish certain checkpoints to measure effectiveness of software processes and accuracy of software estimates during the project execution. Business measurements should also be established upfront, and collected before the project begins and after the project is implemented .

3.4 BUSINESS APPLICATION DEVELOPMENT 3.4.4 Risk Associated With Software Development One type of risk is business risk relating to the likelihood that the new system may not meet the users’ business needs, requirements and expectations. For example, the business requirements that were to be addressed by the new system are still unfulfilled, and the process has been a waste of resources. In such a case, even if the system is implemented, it will most likely be under-utilized and not maintained, making it obsolete in a short period of time.

When introducing thin client architecture, which of the following risks regarding servers is significantly increased? A. Integrity B. Concurrency C. Confidentiality D. Availability Chapter 3 Question 8

3.4 BUSINESS APPLICATION DEVELOPMENT Software project risks exist at multiple levels, such as: • Within the project, e.g., risks associated with not identifying the right requirements to deal with the business problem or opportunity the system is meant to address, and not managing the project to deliver within time and cost constraints • With suppliers, e.g., failure to clearly communicate requirements and expectations resulting in suppliers not delivering on time, at expected cost and/or with deficient quality 3.4.4 Risk Associated With Software Development . . .

3.4 BUSINESS APPLICATION DEVELOPMENT • Within the organization, e.g., stakeholders not providing needed inputs or committing resources to the project, and changing organizational priorities and politics • With the external environment, e.g., impacts on the projects caused by the actions and changing preferences of customers, competitors, government/regulators and economic conditions . . . Risk Associated With Software Development

3.4 BUSINESS APPLICATION DEVELOPMENT . . . Risk Associated With Software Development The IS auditor should also review the management discipline over a project related to the following: • The project meeting cooperative goals and objectives • Project planning, including effective estimates of resources and time. • Control over scope creep where a software baseline does not exist, meaning that requirements can be added into the software design and the development process is uncontrolled.

3.4 BUSINESS APPLICATION DEVELOPMENT . . . Risk Associated With Software Development • Management tracking over software design and development activities • Senior management support provided to the software project’s design and development efforts • Periodic review and risk analysis in each project phase

3.4 BUSINESS APPLICATION DEVELOPMENT 3.4.5 Use of Structured Analysis, Design and Development Techniques • Develop system context diagrams (e.g., high-level business process flow schema). • Perform hierarchical data flow/control flow decomposition. • Develop control transformations. • Develop minispecifications. • Develop data dictionaries. • Define all external events — inputs from external environment. • Define single transformation data flow diagrams from each external event.

3.5 ALTERNATIVE APPLICATION DEVELOPMENT APPROACHES In the face of increasing system complexity and the need to implement new systems quicker to achieve benefits before the business changes, software development practitioners have developed alternative development strategies to reduce development time and maintenance costs or to improve the quality of software.

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT ORGANIZATION Given these factors, other approaches an IS auditor may encounter include: • Incremental or progressive development — The system is built in stages or releases rather than being delivered in its entirety in one implementation. The separate releases are often still large undertakings that operate as discrete subprojects.

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT ORGANIZATION • Iterative development — This involves building the system in iterations or increments, with feedback occurring after each increment to facilitate any necessary adjustment of project plans and software development products.

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT ORGANIZATION • Evolutionary development — Prototyping is used to build a working model that is used to elicit/verify requirements and explore design issues. Eventually, the prototype is hardened, so it can be implemented into production, or perhaps the system is recoded based on learning from the prototype

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT ORGANIZATION • Spiral development — A series of prototypes is used to develop a solution, to the point of detailed design, build and test. The solution spirals out from the initial limited prototype to become progressively more expansive and detailed.

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT ORGANIZATION • Agile development — The project is broken down into relatively short, time-boxed iterations. From the earliest iterations, the emphasis is to produce actual working functionality, although software release may not always coincide with completion of an increment.

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT ORGANIZATION 3.6.1 Agile Development: Agile development refers to a family of similar development processes that espouse a nontraditional way of developing complex systems. One of the first agile processes emerged in the early 1990s —Scrum.

ALTERNATIVE APPLICATION DEVELOPMENT APPROACHES Agile Development: Agile development processes have a number of common characteristics: • The use of small, time-boxed subprojects or iterations. In this instance, each iteration forms the basis for planning the next iteration. • Replanning the project at the end of each iteration (referred to as a “sprint” in Scrum) including reprioritizing requirements, identifying any new requirements and determining within which release delivered functionality should be implemented.

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT ORGANIZATION 3.6.1 Agile Development: • Relatively greater reliance, compared to traditional methods, on tacit knowledge. • A heavy influence on mechanisms to effectively disseminate tacit knowledge and promote teamwork. Team meetings to verbally discuss progress and issues occur daily but with strict time limits. • At least some of the agile methods stipulate pair-wise programming (two persons code the same part of the system) as a means of sharing knowledge and as a quality check.

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT ORGANIZATION 3.6.1 Agile Development: • A change in the role of the project manager, from one primarily concerned with planning the project, allocating tasks and monitoring progress to that of a facilitator and advocate. Responsibility for planning and control devolves to the team members.

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT ORGANIZATION 3.6.1 Agile Development: Agile development does not ignore the concerns of traditional software development but approaches them from a different perspective: • Agile development only plans for the next iteration of development in detail, rather than planning subsequent development phases far out in time. • Agile development’s adaptive approach to requirements does not emphasize managing a requirements baseline.

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT ORGANIZATION 3.6.1 Agile Development: • Agile development’s focus is to quickly prove an architecture by building actual functionality vs. formally defining “early-on” software and data architecture in increasingly more detailed models and descriptions. • Agile development assumes limits to defect testing, but attempts to validate functions through a frequent-build test cycle and correct problems in the next subproject, before too much time and cost is incurred. • Agile development does not emphasize defined and repeatable processes, but instead performs and adapts its development based on frequent inspections.

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT ORGANIZATION 3.6.2 Prototyping Prototyping, also known as heuristic or evolutionary development, is the process of creating a system through controlled trial and error procedures to reduce the level of risks in developing the system. That is, it enables the developer and customer to understand and react to risks at each evolutionary level (using prototyping as a risk reduction mechanism).

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT ORGANIZATION 3.6.2 Prototyping There are two basic methods or approaches to prototyping: 1. Build the model to create the design (i.e., the mechanism for defining requirements). Then, based on that model, develop the system design with all the performance, quality and maintenance features needed. 2. Gradually, build the actual system that will operate in production using a fourth-generation language (4GL) that has been determined to be appropriate for the system being built.

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT ORGANIZATION 3.6.3 Rapid Application Development: The techniques include the use of: • Small, well-trained development teams • Evolutionary prototypes • Integrated power tools that support modeling, prototyping and component reusability • A central repository • Interactive requirements and design workshops • Rigid limits on development time frames

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT ORGANIZATION 3.6.3Rapid Application Development: The RAD methodology has four major stages: 1. The concept definition stage defines the business functions and data subject areas that the system will support and determines the system scope. 2. The functional design stage uses workshops to model the system’s data and processes and build a working prototype of critical system components.

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT ORGANIZATION 3.6.3 Rapid Application Development: 3. The development stage completes the construction of the physical database and application system, builds the conversion system, and develops user aids and deployment work plans. 4. The deployment stage includes final-user testing and training, data conversion and the implementation of the application system.

3.7 ALTERNATIVE DEVELOPMENT METHODS 3.7.1 Data – Oriented System Development Data-oriented system development (DOSD) is a method for representing software requirements by focusing on data and their structure. There are institutions, such as stock exchanges, and service providers, such as airlines, telephone companies, etc., that generate time-dependent data.

3.7 ALTERNATIVE DEVELOPMENT METHODS 3.7.2 Object – Oriented System Development Object-oriented system development (OOSD) is the process of solution specification and modeling where data and procedures can be grouped into an entity known as an object. An object’s data are referred to as its attributes, and its functionality is referred to as its methods.

3.7 ALTERNATIVE DEVELOPMENT METHODS Applications that use object – oriented technology are: • Web applications • E-business applications • Computer-aided software engineering (CASE) for software development • Office automation for e-mail and work orders • Artificial intelligence • Computer-aided manufacturing (CAM) for production and process control

3.7 ALTERNATIVE DEVELOPMENT METHODS 3.7.3 Component – Based Development The basic types of components are: • In-process client components—These components must run from within a container of some kind, such as a web browser; they cannot run on their own. • Stand-alone client components—Applications that expose services to other software can be used as components. Well-known examples are Microsoft’s Excel and Word.

3.7 ALTERNATIVE DEVELOPMENT METHODS 3.7.3 Component – Based Development • Stand-alone server components—Processes running on servers that provide services in standardized ways can be components. • In-process server components—These run on servers within containers. Examples include Microsoft’s Transaction Server (MTS) and Sun’s Enterprise Java Beans (EJB).

3.7 ALTERNATIVE DEVELOPMENT METHODS 3.7.4 Web – Based Application Development Web-based application development is an important emerging software development approach designed to achieve easier and more effective integration of code modules within and between enterprises.

3.7 ALTERNATIVE DEVELOPMENT METHODS 3.7.5 Reengineering: Reengineering is a process of updating an existing system by extracting and reusing design and program components. This process is used to support major changes in the way an organization operates. A number of tools are now available to support this.

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: A. inform management of the finding and determine whether management is willing to accept the potential material risk of not having that preventive control. B. 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. C. recommend that this and all control procedures that existed before the process was reengineered be included in the new process. D. develop a continuous audit approach to monitor the effects of the removal of the preventive control . Chapter 3 Question 1

3.7 ALTERNATIVE DEVELOPMENT METHODS 3.7.6 Reverse Reengineering: • Decompiling object or executable code into source code and using it to analyze the program • Utilizing the reverse-engineered application as a black box test and unveiling its functionality using test data

3.7 ALTERNATIVE DEVELOPMENT METHODS 3.7.6 Reverse Reengineering: The major advantages of reverse engineering are: • Faster development and reduced SDLC duration • The creation of an improved system using the reverse-engineered application drawbacks

3.7 ALTERNATIVE DEVELOPMENT METHODS 3.7.6 Reverse Reengineering: The IS auditor should be aware of the following risks: • Software license agreements often contain clauses prohibiting the licensee from reverse engineering the software, so that any trade secrets or programming techniques are not compromised. • Decompilers are relatively new tools with functions that depend on specific computers, operating systems and programming languages.

The physical architecture analysis, the definition of a new one and the necessary road map to move from one to the other is a critical task for an IT department. Its impact is not only economic, but also technological, as it decides many other choices downstream, such as operational procedures, training needs, installation issues and total cost of ownership (TCO). 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

In this first section, steps are listed to arrive at the choice of a good physical architecture and the way to define a possible road map for supporting the migration of the technical architecture to the new one to reach the following goals: • To successfully analyze the existing architecture • To design a new architecture, which takes into account the existing architecture as well as a company’s particular constraints, such as: – Reduce costs – Increase functionality – Minimum impact on daily work – Security and confidentiality issues – Progressive migration to the new architecture 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

• To write the functional requirements of this new architecture • To develop a proof of concept based on these functional requirements: – To characterize price, functionality, and performance – To identify additional requirements that will be used later 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Thus, ICT departments often face these requirements. The suggested solution must: • Ensure alignment of the IT systems with corporate standards • Provide appropriate levels of security • Integrate with current IT systems • Consider IT industry trends • Provide future operational flexibility to support business processes • Allow for projected growth in infrastructure without major upgrades • Include technical architecture considerations for information security, secure storage, etc. 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

• Ensure cost-effective, day-to-day operational support • Allow the usage of standardized hardware and software • Maximize ROI, cost transparency and operational efficiency 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

3.8.1 Project Phases of Physical Arquitecture Analysis: 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

3.8.1 Project Phases of Physical Arquitecture Analysis: Review of existing arquitecture Special care must be taken in characterizing all the operational constraints that impact physical architecture, such as: • Ground issues • Size limits • Weight limits • Current supply • Physical security issues 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

3.8.1 Project Phases of Physical Arquitecture Analysis: Analysis and Design After reviewing the existing architecture, the design of the actual physical architecture has to be analyzed and again compared against best practices and business requirements. 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

3.8.1 Project Phases of Physical Arquitecture Analysis: Draft Functional Requirements With the first physical architecture design in hand, the first (draft) of functional requirements is composed. They are the input for the next step and the vendor selection process. 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

3.8.1 Project Phases of Physical Arquitecture Analysis: Vendor and Product Selection While the draft functional requirements are written, the vendor selection process is started in parallel. This process is described in detail later in this section. 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

3.8.1 Project Phases of Physical Arquitecture Analysis: Writing Functional Requirements After finishing the draft functional requirements and feeding the second part of this project, the functional requirements document is written, which will be introduced at the second architecture workshop with staff from all affected parties. 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

3.8.1 Project Phases of Physical Arquitecture Analysis: Proof of Concept • The basic setup of the core security infrastructure • Correct functionality of auditing components • Basic, but functional implementation of security measures as defined • Secured transactions • Characterization in terms of installation constraints and limits (server size, server current consumption, server weight, server room physical security) • Performance • Resiliency • Funding and costing model 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

3.8.1 Planning implementation of Infrastructure: To ensure the quality of the results, it is necessary to use a phased approach to fit the whole puzzle together. It is also fundamental to set up the communication processes to other projects like the one described earlier. 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

3.8.2 Planning implementation of infrastructure 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

3.8.2 Planning implementation of infrastructure : - Procurement Phase 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

3.8.2 Planning implementation of infrastructure : - Delivery Time 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

3.8.2 Planning implementation of infrastructure : - Installation Plan 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

3.8.2 Planning implementation of infrastructure : - Installation Test Plan 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

3.8.3 Critical Success Factors Include: • The right skilled staff must attend workshops and participate for the whole project duration to avoid delays. • The documentation needed for carrying out the work needs to be ready at project start-up. • Decision makers must be involved at all steps, to ensure that all necessary decisions can be made quickly. • To get prepared, part one of the project (Analysis of Physical Architecture) must be completed and the needed infrastructure decisions must be made. 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

3.8.4 Hardware Acquisition: Selection of a computer hardware and software environment frequently requires the preparation of a specification for distribution to hw / sw vendors and criteria for evaluating vendor proposals. This specification is sometimes presented to vendors in the form of an invitation to tender (ITT), also known an RFP. 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

For acquiring a system the ITT, or specification, should include the following: • Organizational descriptions indicating whether the computer facilities are centralized or decentralized, distributed or outsourced • Information processing requirements, such as: – Major, existing application systems and future application systems – Workload and performance requirements – Processing approaches 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

• Hardware requirements, such as: – CPU speed – Disk space requirements – Memory requirements – Number of CPUs required – Peripheral devices – Data preparation/input devices that accept and convert data for machine processing – Direct entry devices – Networking capability – Number of terminals or nodes the system needs to support 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

• System software applications, such as: – Operating system software (current version and any required upgrades) – Compilers – Program library software – Database management software and programs – Communications software – Access control software 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

• Support requirements, such as: – System maintenance (for preventive, detective (fault reporting) or corrective purposes) – Training (user and technical staff) – Backups (daily and disaster backups) • Adaptability requirements, such as: – HW / SW upgrade capabilities – Compatibility with existing hw/sw platforms – Changeover to other equipment capabilities 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

• Constraints, such as: – Staffing levels – Existing hardware capacity – Delivery dates • Conversion requirements, such as: – Test time for the hw/sw – System conversion facilities – Cost/pricing schedule 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Acquisition Steps: • Testimonials or visits with other users • Provisions for competitive bidding • Analysis of bids against requirements • Comparison of bids against each other, using predefined evaluation criteria • Analysis of the vendor’s financial condition • Analysis of the vendor’s capability to provide maintenance and support 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Acquisition Steps: • Review of delivery schedules against requirements • Analysis of hw/sw upgrade capability • Analysis of security and control facilities • Evaluation of performance against requirements • Review and negotiation of price • Review of contract terms • Preparation of a formal written report summarizing the analysis for each of the alternatives and justifying the selection based on benefits and cost 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Acquisition Steps: The criteria and data used for evaluating vendor proposals should be properly planned. The following are some of the criteria that should be considered in the evaluation process: • Turnaround time—The time that the helpdesk or vendor takes to fix a problem from the moment it is logged in • Response time—The time a system takes to respond to a specific query by the user 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Acquisition Steps: • System reaction time—The time taken for logging into a system or getting connected to a network • Throughput—The quantity of useful work made by the system per unit of time. • Workload—The capacity to handle the required volume of work, or the volume of work that the vendor’s system can handle in a given time frame • Compatibility—The capability of an existing application to run successfully on the newer system supplied by the vendor 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Acquisition Steps: • Capacity—The capability of the newer system to handle a number of simultaneous requests from the network for the application and the volume of data that it can handle from each of the users • Utilization—The system availability time vs. the system downtime 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

3.8.5 System Software Acquisition: Every time a technological development has allowed for increased computing speeds or new capabilities, these have been absorbed immediately by the demands placed on computing resources by more ambitious applications. Consequently, improvements have led to decentralized, interconnected open systems through functions bundled in operating system software to meet these needs. For example, network management and connectivity are features now found in most operating systems. 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

3.8.5 System Software Acquisition: When selecting new system software, a number of business and technical issues must be considered, including: • Business, functional and technical needs and specifications • Cost and benefit(s) • Obsolescence • Compatibility with existing systems • Security • Demands on existing staff • Training and hiring requirements • Future growth needs • Impact on system and network performance 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

3.8.6 System Software Implementation: System software implementation involves identifying features, configuration options and controls for a standard configuration to apply across the organization. 3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES 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. This requires that IS management and personnel are aware of and involved in the system software change process. 3.8.7 System Software Change Control Procedures:

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES System maintenance practices refer primarily to the process of managing change to application systems while maintaining the integrity of both the production source and executable code. Once a system is moved into production, it seldom remains static.

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES The change management process begins with authorizing changes to occur. For this purpose, a methodology should exist for prioritizing and approving system change requests. Change requests are initiated from end users as well as operational staff, and system development/maintenance staff. 3.9.1 Change Management Process Overview:

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES • That existing functionality is not damaged by the change • That system performance is not degraded because of the change • That no security exposures have been created because of the change Testing Changed Programs:

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES • 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 assessed . Auditing Program Changes:

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES • The change request should be documented on a standard form, paying particular attention to the following: – The change specifications should be adequately described, a cost analysis developed and a target date established. – The change form should be signed by the user to designate approval. – The change form should be reviewed and approved by programming management. – The work should be assigned to an analyst, programmer and programming group leader for supervision. Auditing Program Changes:

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES • A sample of program changes made during the audit period should be selected and traced to the maintenance form to determine whether the changes are authorized, check that the form has appropriate approvals, and compare the date on the form with the date of production update for agreement. • If an independent group updates the program changes in production, the IS auditor should determine before the update whether procedures exist to ensure possession of the change request form. Auditing Program Changes:

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES There may be times when emergency changes are required to resolve system problems and enable critical “production job” processing to continue. Procedures should primarily exist in the application’s operations manual to ensure emergency fixes can be performed without compromising the integrity of the system. Emergency Changes:

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES Once user management has approved the change, the modified programs can be moved into the production environment. A group that is independent of computer programming should perform the migration of programs from test to production. Groups such as computer operations, quality assurance or a designated change control group should perform this function. Deploying Changes Back into Production:

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES • The programmer has access to production libraries containing programs and data including object code. • The user responsible for the application was not aware of the change (no user signed the maintenance change request approving the start of the work). • A change request form and procedures were not formally established. • The appropriate management official did not sign the change form approving the start of the work. Change Exposures:

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES • The user did not sign the change form signifying acceptance before the change was updated. • The changed source code was not properly reviewed by the appropriate programming personnel. • The appropriate management official did not sign the change form approving the program for update to production. • The programmer put in extra code for personal benefit . • Changes received from the acquired software vendor were not tested or the vendor was allowed to load the changes directly into production/site. Change Exposures:

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES Because of the difficulties associated with exercising control over programming maintenance activities, some organizations implement configuration management systems. In a configuration management system, maintenance requests must be formally documented and approved by a change control group . 3.9.2 Configuration Management:

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES As part of the software configuration management task, the maintainer performs the following task steps: 1. Develop the configuration management plan. 2. Baseline the code and associated documents. 3. Analyze and report on the results of configuration control. 4. Develop the reports that provide configuration status information. 5. Develop release procedures. 6. Perform configuration control activities, such as identification and recording of the request. 7. Update the configuration status accounting database. 3.9.2 Configuration Management:

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES Tools will support change management and release management by providing automated support for: Identification of items affected by a proposed change to assist with impact assessment 2. Recording configuration items affected by authorized changes 3. Implementation of changes in accordance with authorization records. 4. Registering of configuration item changes when authorized changes and releases are implemented. 5. Recording of baselines related to releases to which to revert with known consequences. 3.9.2 Configuration Management:

3.10 SYSTEM DEVELOPMENT TOOLS & PRODUCTIVITY AIDS Code generators are tools, often incorporated with CASE products, that generate program code based upon parameters defined by a systems analyst or on data/entity flow diagrams developed by the design module of a CASE product. 3.10.1 Code Generators:

3.10 SYSTEM DEVELOPMENT TOOLS & PRODUCTIVITY AIDS Application development efforts require collecting, organizing and presenting a substantial amount of data at the application, systems and program levels. A substantial amount of the application development effort involves translating this information into program logic and code for subsequent testing, modification and implementation. This often is a time consuming process, but it is necessary to develop, use and maintain computer applications. 3.10.2 Computer - Aided Software Engineering:

3.10 SYSTEM DEVELOPMENT TOOLS & PRODUCTIVITY AIDS CASE products are generally divided into three categories: Upper CASE—These products are used to describe and document business and application requirements. Middle CASE—These products are used for developing the detailed designs. Lower CASE—These products are involved with the generation of program code and database definitions. 3.10.2 Computer - Aided Software Engineering:

3.10 SYSTEM DEVELOPMENT TOOLS & PRODUCTIVITY AIDS The IS auditor should gain assurances that approvals are obtained for the appropriate specifications, users continue to be involved in the development process and investments in CASE tools yield benefits in quality and speed. Other key issues the IS auditor needs to consider with CASE include the following: 3.10.2 Computer - Aided Software Engineering:

3.10 SYSTEM DEVELOPMENT TOOLS & PRODUCTIVITY AIDS • CASE tools help in the application design process, but 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, but there needs to be a methodology in place for CASE to be effective. • The integrity of data moved between CASE products or between manual and CASE processes needs to be monitored and controlled. 3.10.2 Computer - Aided Software Engineering:

3.10 SYSTEM DEVELOPMENT TOOLS & PRODUCTIVITY AIDS • Changes to the application should be reflected in stored CASE product data. • Just like a traditional application, application controls need to be designed. • The CASE repository (the database that stores and organizes the documentation, models and other outputs from the different phases) needs to be secured on a need-to-know basis. 3.10.2 Computer - Aided Software Engineering:

3.10 SYSTEM DEVELOPMENT TOOLS & PRODUCTIVITY AIDS While a standard definition of a 4GL does not exist, the common characteristics of 4GLs are the following: • Nonprocedural language—Most 4GLs do not obey the procedural paradigm of continuous statement execution and subroutine call and control structures. • Environmental independence (portability)—Many 4GLs are portable across computer architectures, operating systems and telecommunications monitors. 3.10.3 Fourth Generation Languages:

3.10 SYSTEM DEVELOPMENT TOOLS & PRODUCTIVITY AIDS • Software facilities—These facilities include the ability to design or paint retrieval screen formats, develop computer-aided training routines or help screens, and produce graphical outputs. • Programmer workbench concepts—The programmer has access through the terminal to easy filing facilities, temporary storage, text editing and operating system commands. • Simple language subsets—4GLs generally have simple language subsets that can be used by less-skilled users in an information center. 3.10.3 Fourth Generation Languages:

3.10 PROCESS IMPROVEMENT PRACTICES “ Business is in reality the underlying business process and successful business implies efficient underlying business processes. Everything else that constitutes a business is losing its uniqueness and becoming a commodity. It is no wonder that the efficient organization of processes is becoming a boardroom agenda the world over.” (N. S. Nagaraj et al., BPM Part I: An Emerging Trend, SETLabs, 2001) 3.11.1 Business Process Reengineering and Process Change Projects:

3.11 PROCESS IMPROVEMENT PRACTICES 3.11.1 Business Process Reengineering and Process Change Projects:

3.11 PROCESS IMPROVEMENT PRACTICES 3.11.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.

3.11 PROCESS IMPROVEMENT PRACTICES 3.11.1 Business Process Reengineering and Process Change Projects: As a reengineering process takes hold, new results begin to emerge: • New business priorities, based on value and customer requirements • A concentration on process as a means of improving product, service and profitability • New approaches to organizing and motivating people inside and outside the enterprise • New approaches to the use of technologies in developing, producing and delivering goods and services

3.11 PROCESS IMPROVEMENT PRACTICES 3.11.1 Business Process Reengineering and Process Change Projects: • As a subset, new approaches to the use of information as well as powerful and more accessible information technologies • Refined roles for suppliers, including outsourcing, joint development, quick response, just-in-time inventory and support • Often, redefined roles for clients and customers, providing them with more direct and active participation in the enterprise’s business process

3.11 PROCESS IMPROVEMENT PRACTICES 3.11.1 Business Process Reengineering and Process Change Projects: 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, typically referred to as an elementary process, which is a unit of work performed with a definitive input and output.

3.11 PROCESS IMPROVEMENT PRACTICES 3.11.1 Business Process Reengineering and Process Change Projects: • Identify customers, process-based managers or process owners responsible for beginning-to-end processes. • Document the elementary process-related profile information, including: – Duration – Trigger – Frequency – Effort – Responsibility – Input and output – External interfaces – System interaction – Risk and control information – Performance measurement information – Identified problematic areas and its root causes

3.11 PROCESS IMPROVEMENT PRACTICES BPR Methods & Techniques BenchMarking Process: Benchmarking is about improving business processes. It is defined as a continuous, systematic process for evaluating the products, services and work processes of organizations recognized as representing best practices for the purpose of organizational improvement.

3.11 PROCESS IMPROVEMENT PRACTICES BPR Methods & Techniques BenchMarking Process: 1. Plan—In the planning stage, critical processes are identified for the benchmarking exercise. 2. Research—The team should collect baseline data about its own processes, before collecting this data about others. 3. Observe—The next step is to collect data and visit the benchmarking partner. 4. Analyze—This step involves summarizing and interpreting the data collected and analyzing the gaps between an organization’s process and its partner’s process.

During which of the following steps in the business process reengineering should the benchmarking team visit the benchmarking partner? A. Observation B. Planning C. Analysis D. Adaptation Chapter 3 Question 10

3.11 PROCESS IMPROVEMENT PRACTICES BPR Methods & Techniques BenchMarking Process: 5. Adapt—Adapting the results of benchmarking can be the most difficult step. In this step, the team needs to translate the findings into a few core principles and work down from principles to strategies, to action plans. 6. Improve—Continuous improvement is the key focus in a benchmarking exercise. Benchmarking links each process in an organization with an improvement strategy and organizational goals.

3.11 PROCESS IMPROVEMENT PRACTICES BPR Audit & Evaluation Techniques: When reviewing an organization’s business process change (reengineering) efforts, IS auditors must determine whether: • The 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 change management team has documented lessons to be learned after the completion of the BPR/process change project .

3.11 PROCESS IMPROVEMENT PRACTICES 3.11.2 ISO 9126: Attributes evaluated include the following: • Functionality — • Reliability — • Usability — • Efficiency — • Maintainability — • Portability —

3.11 PROCESS IMPROVEMENT PRACTICES 3.11.3 Software Capability Maturity Model: The software capability maturity model (CMM), developed by Carnegie Melon’s Software Engineering Institute and various industry and government affiliates in the early 1990s, is a process maturity model or framework that helps organizations improve their software life cycle processes.

3.11 PROCESS IMPROVEMENT PRACTICES 3.11.3 Software Capability Maturity Model: The five maturity levels attainable by software organizations include: Initial — Repeatable — Defined — Managed — Optimizing —

3.11 PROCESS IMPROVEMENT PRACTICES 3.11.4 Capability Maturity Model Integration: Supporters of the CMMI see it as less directly aligned with the traditional waterfall approach toward development and better aligned with contemporary software development practices including: • Iterative development • Early definition of architecture • Model-based design notation • Component-based development • Demonstration-based assessment of intermediate development products • Use of scalable, configurable processes

3.11 PROCESS IMPROVEMENT PRACTICES 3.11.5 ISO 15504: ISO/IEC TR 15504, also known as SPICE (Software Process Improvement and Capability Determination), is based on CMM and Bootstrap and was first published in 1998 (ISO/IEC TR 15504:1998). Based on the feedback of more than 4,000 assessments, it has been republished during 2003-2005 as a full international standard.

3.11 PROCESS IMPROVEMENT PRACTICES 3.11.4 ISO 15504: Reference models for SPICE include: • Software life cycle processes—Through ISO/IEC 12207 AMD1/2 • System life cycle processes—Through ISO/IEC 15288 • Human-centered life cycle processes—Through ISO 18529 • Component-based development processes—Through the OOSPICE project • IT service management processes—Through a SPICE user group initiative • Quality management system processes—Through SPICE for 9000 (S9K) • Automotive embedded software—Through Automotive SPICE • Medical device software—Through the Medi SPICE initiative

3.11 PROCESS IMPROVEMENT PRACTICES 3.11.5 ISO 15504:

3.12 APPLICATION CONTROLS Application controls refer to the transactions and data relating to each computer-based application system; therefore, they are specific to each. The objectives of application controls, which may be manual or programmed, are to ensure the completeness and accuracy of the records and the validity of the entries made therein resulting from both manual and programmed processing.

3.12 APPLICATION CONTROLS 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

3.12 APPLICATION CONTROLS • Identifying the significant application components and the flow of transactions through the system, and gaining a detailed understanding of the application by reviewing the available documentation and interviewing appropriate personnel • Identifying the application control strengths, and evaluating the impact of the control weaknesses on the development of a testing strategy by analyzing the accumulated information The IS Auditor’s tasks include:

3.12 APPLICATION CONTROLS • Testing the controls to ensure their functionality and effectiveness by applying appropriate audit procedures • Evaluating the control environment to determine that control objectives were achieved through analyzing the test results and other audit evidence • Considering the operational aspects of the application to ensure its efficiency and effectiveness by comparing the system with efficient programming standards, analyzing procedures used and comparing them to management’s objectives for the system The IS Auditor’s tasks include:

3.12 APPLICATION CONTROLS Input control procedures must ensure that every transaction to be processed is received, processed and recorded accurately and completely. These controls should ensure that only valid and authorized information is input and that these transactions are only processed once. In an integrated systems environment, output generated by one system is the input for another system. 3.12.1 Input / Origination Controls:

3.12 APPLICATION CONTROLS Types of authorization include: • Signatures on batch forms or source documents • Online access controls • Unique Passwords • Terminal or client workstation identification • Source documents Input Authorization:

3.12 APPLICATION CONTROLS Types of batch controls include: • Total monetary amount — • Total items — • Total documents — • Hash totals — Batch Controls and Balancing:

3.12 APPLICATION CONTROLS Types of batch balancing include: • Batch registers — • Control accounts — • Computer agreement — Batch Controls and Balancing:

3.12 APPLICATION CONTROLS Input error handling can be processed by: • Rejecting only transactions with errors — • Rejecting the whole batch of transactions — • Holding the batch in suspense — • Accepting the batch and flagging error transactions — Error reporting and handling:

3.12 APPLICATION CONTROLS Input control technique include: • Transaction log — • Reconciliation of data — • Documentation — • Error correction procedures — These include: – Logging of errors, Timely corrections, Upstream resubmission, Approval of corrections, Suspense file, Error file, Validity of corrections • Anticipation — • Transmittal log — • Cancellation of source documents — Error Reporting and Handling:

3.12 APPLICATION CONTROLS Processing procedures and controls ensure the reliability of application program processing. IS auditors need to understand the procedures and controls that can be exercised over processing to evaluate what exposures are covered by these controls and what exposures remain. 3.12.2 Procesing procedures & controls:

3.12 APPLICATION CONTROLS Procedures should be established to ensure that input data are validated and edited as close to the time and point of origination as possible. Preprogrammed input formats ensure that data are input to the correct field in the correct format. If input procedures allow supervisor overrides of data validation and editing, automatic logging should occur. Data validation & editing procedures:

3.12 APPLICATION CONTROLS Processing controls ensure the completeness and accuracy of accumulated data. They ensure that data on a file/database remains complete and accurate until changed as a result of authorized processing or modification routines. The following are processing control techniques that can be used to address the issues of completeness and accuracy of accumulated data: Processing Controls:

A hash total of employee numbers is part of the input to a payroll master file update program. The program compares the hash total with the corresponding control total. What is the purpose of this procedure ? A. Verify that employee numbers are valid. B. Verify that only authorized employees are paid. C. Detect errors in payroll calculations. D. Detect the erroneous update of records. Chapter 3 Question 2

3.12 APPLICATION CONTROLS • Manual recalculations — • Editing — • Run-to-run totals — • Programmed controls — • Reasonableness verification of calculated amounts — • Limit checks on calculated amounts — • Reconciliation of file totals — • Exception reports — Processing Controls:

APPLICATION CONTROLS • System control parameters — • Standing data — • Master data/balance data — • Transaction files — Data File Control Procedures:

3.12 APPLICATION CONTROLS Output controls provide assurance that the data delivered to users will be presented, formatted and delivered in a consistent and secure manner. • Logging and storage of negotiable, sensitive and critical forms in a secure place • Computer generation of negotiable instruments, forms and signatures • Report distribution • Balancing and reconciling • Output error handling • Output report retention • Verification of receipt of reports 3.12.3 Output Controls:

3.12 APPLICATION CONTROLS Specific matters to consider in the business process control assurance are: • Process maps • Process controls • Assess business risks within the process • Benchmark with the best practices • Roles and responsibilities • Activities and tasks • Data restrictions 3.12.4 Business Process Control Assurance:

3.12 AUDITING APPLICATION CONTROLS • Identifying the significant application components and the flow of transactions through the system • Identifying the application control strengths and evaluating the impact of the control weaknesses to develop a testing strategy by analyzing the accumulated information • Reviewing application system documentation to provide an understanding of the functionality of the application The IS auditor´s tasks include the following:

3.13 AUDITING APPLICATION CONTROLS The following documentation should be reviewed to gain an understanding of an application’s development: – System development methodology documents — – Functional design specifications — – Program changes — – User manuals — – Technical reference documentation — The IS auditor´s tasks include the following:

3.13 AUDITING APPLICATION CONTROLS • The quality of internal controls • Economic conditions • Recent accounting system changes • Time elapsed since last audit • Complexity of operations • Changes in operations/environment • Recent changes in key positions • Time in existence • Competitive environment 3.13.2 Risk Assessment Model to Analyze Application Controls

3.13 AUDITING APPLICATION CONTROLS • Assets at risk • Prior audit results • Staff turnover • Transaction volume • Regulatory agency impact • Monetary volume • Sensitivity of transactions • Impact of application failure 3.13.2 Risk Assessment Model to Analyze Application ’s Control:

3.13 AUDITING APPLICATION CONTROLS Some of the user procedures that should be observed and tested include: • Separation of duties — • Authorization of input — • Balancing — • Error control and correction — • Distribution of reports — • Review and testing of access authorizations and capabilities — 3.13.3 Observing and Testing user ’s Performing Procedures:

3.13 AUDITING APPLICATION CONTROLS Data integrity testing is a set of substantive tests that examines the accuracy, completeness, consistency and authorization of data presently held in a system. It employs testing similar to that used for input control. 3.13.4 Data Integrity Testing:

3.13 AUDITING APPLICATION CONTROLS • Atomicity — • Consistency — • Isolation — • Durability — 3.13.5 Data Integrity in Online Transaction Processing Systems:

3.13 AUDITING APPLICATION CONTROLS 3.13.6 Test Application Systems:

3.13 AUDITING APPLICATION CONTROLS 3.13.7 Continuous Online Auditing: Continuous online auditing is becoming increasingly important in today’s e-business world, because it provides a method for the IS auditor to collect evidence on system reliability, while normal processing takes place. The approach allows IS auditors to monitor the operation of such a system on a continuous basis and to gather selective audit evidence through the computer.

3.13 AUDITING APPLICATION CONTROLS 3.13.8 Online Auditing Techniques: 1. Systems control audit review file and embedded audit modules (SCARF/EAM) — 2. Snapshots — 3. Audit hooks — 4. Integrated test facilities (ITF) — 5. Continuous and intermittent simulation (CIS) —

3.13 AUDITING SYSTEM DEVELOPMENT ACQUISITION AND MAINTENANCE 3.13.8 Online Auditing Techniques: The IS auditor’s tasks in system development, acquisition and maintenance generally include the following: • Determine the main components, objectives and user requirements • Determine and rank the major risks to, and exposures • Identify controls to mitigate the risks • Advise the project team regarding the design of the system and implementation of controls • Monitor the systems development process to ensure that controls are implemented

The IS auditor’s tasks in system development, acquisition and maintenance generally includes various aspects. Tracking information in a change management system includes: – History of all work order activity – History of logins and logouts by programmers – History of program deletions • Participate in post implementation reviews. • Evaluate system maintenance standards and procedures • Test system maintenance procedures • Evaluate the system maintenance process. • Determine the adequacy of production library security 3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION AND MAINTENANCE

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION AND MAINTENANCE 3.14.1 Project Management: Throughout the project management process, the IS auditor should analyze the associated risks and exposures inherent in each phase of the SDLC and ensure the appropriate control mechanisms are in place to minimize these risks in a cost-effective manner.

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION AND MAINTENANCE 3.14.1 Project Management: The IS auditor should review the adequacy of the following project management activities: • Levels of oversight by project committee/board • Risk management methods within the project • Cost management • Processes for planning and dependency management • Reporting processes to senior management • Change control processes • Stakeholder management involvement

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION AND MAINTENANCE 3.14.2 Feasibility Study: The IS auditor should perform the following functions: • Review the documentation produced in this phase for reasonableness. • Determine whether all cost justifications/benefits are verifiable, and present them showing the anticipated benefits to be realized. • Identify and determine the criticality of the need. • Determine if a solution can be achieved with systems already in place. • Determine the reasonableness of the chosen solution.

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION AND MAINTENANCE 3.14.3 Requirement Definitions: The IS auditor should perform the following functions: • Obtain the detailed requirements definition document • Identify the key team members on the project team • Verify that project initiation and cost • Review the conceptual design specifications • Review the conceptual design • Determine whether a reasonable number of vendors received a proposal covering the project scope and user requirements. • Review the user acceptance testing (UAT) specification. • Determine whether the application is a candidate for the use of an embedded audit routine.

When auditing the requirements phase of a software acquisition, the IS auditor 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 acquired. D. review the completeness of the specifications. Chapter 3 Question 7

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION AND MAINTENANCE 3.14.4 Software Acquisition Process: The IS auditor should perform the following functions: • Analyze the documentation from the feasibility study to determine whether the decision to acquire a solution was appropriate. • Review the RFP to ensure it covers the items listed in this section. • Determine whether the selected vendor is supported by RFP documentation. • Attend agenda-based presentations and conference room pilots to ensure that the system matches the vendor’s response to the RFP. • Review the vendor contract prior to its signing to ensure it includes the items listed. • Ensure the contract is reviewed by legal counsel before it is signed.

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION AND MAINTENANCE 3.14.5 Detailed Design and Development: The IS auditor should perform the following functions: • Review the system flowcharts for adherence to the general design. • Review the input, processing and output controls designed into the system for appropriateness. • Interview the key users of the system to determine their understanding of how the system will operate • Assess the adequacy of audit trails to provide traceability and accountability of system transactions. • Verify the integrity of key calculations and processes. • Verify that the system can identify and process erroneous data correctly.

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION AND MAINTENANCE 3.14.5 Detailed Design and Development: • Review the quality assurance results of the programs developed during this phase. • Verify that all recommended corrections to programming errors were made and that the recommended audit trails or embedded audit modules were coded into the appropriate programs.

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION AND MAINTENANCE 3.14.6 Testing: Testing is crucial in determining that the user requirements have been validated, the system is performing as anticipated and the internal controls work as intended. Therefore, it is essential that the IS auditor be involved in reviewing this phase and perform the following: • Review the test plan for completeness • Reconcile control totals and converted data. • Review error reports for their precision in recognizing erroneous data and for resolution of errors.

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION AND MAINTENANCE 3.14.6 Testing: • Verify cyclical processing for correctness • Interview end users of the system for their understanding of new methods, procedures and operating instructions. • Review system and end-user documentation to determine its completeness, and verify its accuracy during the test phase. • Review parallel testing results for accuracy. • Verify that system security is functioning as designed by developing and executing access tests.

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION AND MAINTENANCE 3.14.6Testing: • Review unit and system test plans to determine whether tests for internal controls are planned and performed. • Review the user acceptance testing and ensure that the accepted software has been delivered to the implementation team. The vendor should not be able to replace this version. • Review procedures used for recording and following through on error reports.

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION AND MAINTENANCE 3.14.7 Implementation Phase: The IS auditor should verify that appropriate sign-offs have been obtained prior to implementation, and perform the following: • Review the programmed procedures used for scheduling and running the system along with system parameters used in executing the production schedule. • Review all system documentation to ensure its completeness and that all recent updates from the testing phase have been incorporated. • Verify all conversion of data to ensure they are correct and complete before implementing the system in production.

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION AND MAINTENANCE Post Implementation Review: The IS auditor should perform the following functions: • Determine if the system’s objectives and requirements were achieved. • Determine if the cost benefits identified in the feasibility study are being measured, analyzed and accurately reported to management. • Review program change requests performed to assess the type of changes required of the system. • Review controls built into the system to ensure that they are operating according to design.

An IS auditor is performing a project review to identify whether a new application has met business objectives. Which of the following test reports offers the most assurance that business objectives are met? A. User acceptance B. Performance C. Sociability D. Penetration Chapter 3 Question 9

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION AND MAINTENANCE 3.14.8 Post Implementation Review: • Review operators’ error logs to determine if there are any resource or operating problems inherent within the system. • Review input and output control balances and reports to verify that the system is processing data accurately.

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION AND MAINTENANCE 3.14.9 System Change Procedures & the program Migration Process: In this regard, the IS auditor should consider the following: • The use and existence of a methodology for authorizing, prioritizing and tracking system change requests from the user • Whether emergency change procedures are addressed in the operations manuals • Whether change control is a formal procedure for the user and the development groups

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION AND MAINTENANCE 3.14.9 System Change Procedures & the program Migration Process: • Whether the change control log ensures all changes shown were resolved • The user’s satisfaction with the turnaround—timeliness and cost— of change requests • The adequacy of the security access restrictions over production source and executable modules • The adequacy of the organization’s procedures for dealing with emergency program changes • The adequacy of the security access restrictions over the use of the emergency logon IDs

3.15 BUSINESS APPLICATION SYSTEMS To develop effective audit programs the IS auditor must obtain a clear understanding of the application system under review. Some types of application systems and the related processes are described in the following sections. Numerous financial and operational functions are computerized for the purpose of improving efficiency and increasing the reliability of information.

3.15 BUSINESS APPLICATION SYSTEMS 3.15.1 Electronic Commerce: Electronic commerce (e-commerce), is one of the most popular e-business implementations. It is the buying and selling of goods online, usually via the Internet. Typically, a web site will advertise goods and services, and the buyer will fill in a form on the web site to select the items to be purchased and provide delivery and payment details, or banking services, such as transfers, payment orders, etc. The web site may gather details about customers and offer other items that may be of interest.

3.15 BUSINESS APPLICATION SYSTEMS E – Commerce Models: • 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 —

3.15 BUSINESS APPLICATION SYSTEMS E – Commerce Architectures: There are a large number of choices to be made in determining an appropriate e-commerce architectures. Initially, e-commerce architectures were either two-tiered (i.e., client browser and web server), or three-tiered (i.e., client browser, web server and database server). 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.

3.15 BUSINESS APPLICATION SYSTEMS E – Commerce Risks: • Confidentiality — • Integrity — • Availability — • Authentication and nonrepudiation — • Power shift to customers —

3.15 BUSINESS APPLICATION SYSTEMS E – Commerce Requirements: Some e-commerce requirements include: • Build a business case (IT as an enabler). • Develop a clear business purpose. • Use technology to first improve costs. • Build business case around the four Cs: customers, costs, competitors and capabilities.

3.15 BUSINESS APPLICATION SYSTEMS E – Commerce Audit & Control Issues: • A set of security mechanisms and procedures that, taken together, constitute a security architecture for e-commerce (e.g., Internet firewalls, PKI, encryption, certificates and password management) • Firewall mechanisms that are in place to mediate between the public network (the Internet) and an organization’s private network • A process whereby participants in an e-commerce transaction can be identified uniquely and positively

3.15 BUSINESS APPLICATION SYSTEMS E – Commerce Audit & Control Issues: • Digital signatures, so the initiator of an e-commerce transaction can be uniquely associated with it. Attributes of digital signatures include: – The digital signature is unique to the person using it. – It can be verified. – The mechanism for generating and affixing the signature is under the sole control of the person using it. – It is linked to data in such a manner that if the data are changed, the digital signature is invalidated. • An infrastructure to manage and control public key pairs

3.15 BUSINESS APPLICATION SYSTEMS 3.15.2 Electronic Data Interchange (EDI): EDI, in use for more than 20 years, is one of the first e-commerce applications in use between business partners for transmitting business transactions between organizations with dissimilar computer systems. It involves the exchange and transmittal of business documents, such as invoices, purchase orders and shipping notices, in a standard, machine-processable format.

3.15 BUSINESS APPLICATION SYSTEMS 3.15.2 Electronic Data Interchange (EDI): 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

3.15 BUSINESS APPLICATION SYSTEMS Traditional EDI: Communications handler — EDI interface — The interface consists of two components: – EDI translator – Application interface 3. Application system —

3.15 BUSINESS APPLICATION SYSTEMS Web Based EDI: • Internet-through-Internet service providers offer a 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 formatting standard

3.15 BUSINESS APPLICATION SYSTEMS 3.15.4 Controls in EDI Environment: • Standards should be set to indicate the message format and content are valid to avoid transmission errors. • Controls should be in place to ensure standard transmissions are properly converted for the application software by the translation application. • The receiving organization must have controls in place to test the reasonableness of messages received. This should be based upon a trading partner’s transaction history or documentation received that substantiates special situations.

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

3.15 BUSINESS APPLICATION SYSTEMS 3.15.4 Controls in EDI Environment: • Controls should be established to guard against manipulation of data in active transactions, files and archives. Attempts to change records should be recorded by the system for management review and attention. • Procedures should be established to determine messages are only from authorized parties and that transmissions are properly authorized. • Direct or dedicated transmission channels among the parties should exist to reduce the risk of tapping into the transmission lines.

3.15 BUSINESS APPLICATION SYSTEMS 3.15.4 Controls in EDI Environment: • Data should be encrypted using algorithms agreed to by the parties involved. • Electronic signatures should be in the transmissions to identify the source and destination. • Message authentication codes should exist to ensure that what is sent is received.

3.15 BUSINESS APPLICATION SYSTEMS Receipt of Inbound Transactions: • Use appropriate encryption techniques when using public Internet infrastructures for communication in assuring confidentiality, authenticity and integrity of transactions. • Perform edit checks to identify erroneous, unusual or invalid transactions prior to updating application. • Perform additional computerized checking to assess transaction reasonableness, validity, etc. (Consider expert system front ends for complex comparisons.) • Log each inbound transaction upon receipt. • Use control totals on receipt of transactions.

3.15 BUSINESS APPLICATION SYSTEMS Receipt of Inbound 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 • Maintain a record of the number of messages received/sent • Arrange for security over temporary files and data transfer to ensure that inbound transactions are not altered or erased between time of transaction receipt and application updates.

3.15 BUSINESS APPLICATION SYSTEMS Outbound Transactions: The control considerations for outbound transactions are as follows: • Controlling the set up and change of trading partner details • Comparing transactions with trading partner transaction profiles • Matching the trading partner number to the trading master file, prior to transmission • Limiting the authority of users within the organization to initiate specific EDI transactions • Segregating initiation and transmission responsibilities for high- risk transactions

3.15 BUSINESS APPLICATION SYSTEMS Outbound Transactions: • Documenting management sign-off on programmed procedures and subsequent changes • Logging all payment transactions to a separate file, which is reviewed for authorization before transmission • Segregating duties within the transaction cycle, particularly where transactions are automatically generated by the system • Segregating access to different authorization processes in a transaction cycle

3.15 BUSINESS APPLICATION SYSTEMS Outbound Transactions: • Reporting large (value) or unusual transactions for review prior to or after transmission • Logging outbound transactions in a secure temporary file until authorized and due for transmission • Requiring paperless authorization, which would establish special access to authorization fields (probably two levels, requiring the intervention of different users) within the computer system

3.15 BUSINESS APPLICATION SYSTEMS Auditing EDI: • Internet encryption processes in place to assure authenticity, integrity, confidentiality and nonrepudiation of transactions • Edit checks to identify erroneous, unusual or invalid transactions prior to updating the application • Additional computerized checking to assess transaction reasonableness and validity • Each inbound transaction to ensure it is logged upon receipt • The use of control totals upon receipt of transactions • Segment count totals built into transaction set trailers by the sender

3.15 BUSINESS APPLICATION SYSTEMS Auditing EDI: • Batch control totals built into the functional group headers by the sender • The validity of the sender against trading partner details by: – Using control fields within an EDI message at either the transaction, function, group or interchange level – Using VAN sequential control numbers or reports – Sending an acknowledgement transaction to inform the sender of message receipt. The sender should then match this against a file/log of EDI messages sent.

3.15 BUSINESS APPLICATION SYSTEMS 3.15.5 Electronic Mail: Electronic mail (e-mail), may be the most heavily used feature of the Internet or LANs in an organization. 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 E-mail messages are sent in the same way as most Internet data. When a user sends an e-mail message, it is first broken up by the TCP protocol into IP packets.

3.15 BUSINESS APPLICATION SYSTEMS Security Issues of E-Mail: • Flaws in the configuration of mail server application • Denial-of-service (DoS) attacks may be directed to the mail server denying or hindering valid users an ability to use 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 at some point between the sender and recipient. • Viruses and other types of malicious code may be distributed throughout an organization via e-mail. • Users may send inappropriate, proprietary or other sensitive information via e-mail leading to a legal exposure.

3.15 BUSINESS APPLICATION SYSTEMS Standards of E-Mail Security: • Address the security aspects of the deployment of a mail server through maintenance and administration standards • Ensure that the mail server application is deployed, configured and managed to meet the security policy and guidelines laid down by management • Consider the implementation of encryption technologies to protect user authentication and mail data

3.15 BUSINESS APPLICATION SYSTEMS Standards of E-Mail Security: Digital signatures are a good method of securing e-mail transmissions in that: • The signature can not be forged. • The signature is authentic and encrypted. • The signature cannot be reused (a signature on one document cannot be transferred to another document). • The signed document cannot be altered; any alteration to the document (whether or not it has been encrypted) renders the signature invalid.

3.15 BUSINESS APPLICATION SYSTEMS 3.15.7 Electronic Banking: Banking organizations have been delivering electronic services to consumers and businesses remotely for years. Electronic funds transfer (including small payments and corporate cash management systems), publicly accessible automated machines for currency withdrawal and retail account management are global fixtures. Continuing technological innovation and competition among existing banking organizations and new market entrants has allowed for a much wider array of electronic banking products and services for retail and wholesale banking customers.

3.15 BUSINESS APPLICATION SYSTEMS Risk Management Challenges in E-Banking: • The speed of change relating to technological and service innovation in e-banking is unprecedented. • Transactional e-banking web sites and associated retail and wholesale business applications are typically integrated • E-banking increases banks’ dependence on information technology • The Internet is ubiquitous and global by nature.

3.15 BUSINESS APPLICATION SYSTEMS Risk Management Controls for E-Banking: • Board and management oversight: 1. Effective management oversight of e-banking activities 2. Establishment of a comprehensive security control process 3. Comprehensive due diligence and management oversight process for outsourcing relationships and other third-party dependencies • Security controls: 4. Authentication of e-banking customers 5. Nonrepudiation and accountability for e-banking transactions 6. Appropriate measures to ensure segregation of duties 7. Proper authorization controls within e-banking systems, databases and applications

3.15 BUSINESS APPLICATION SYSTEMS Risk Management Controls for E-Banking: 8. Data integrity of e-banking transactions, records and information 9. Establishment of clear audit trails for e-banking transactions 10. Confidentiality of key bank information • Legal and reputational risk management: 11. Appropriate disclosures for e-banking services 12. Privacy of customer information 13. Capacity, business continuity and contingency planning to ensure availability of e-banking systems and services 14. Incident response planning

3.15 BUSINESS APPLICATION SYSTEMS 3.15.8 Electronic Finance: Changing the face of the financial services industry, electronic finance (e-finance) is enabling new providers to emerge within and across countries, including online banks, brokerages and companies that allow consumers to compare financial services, such as mortgage loans and insurance policies. Advantages of this approach to consumers are: • Lower costs • Increased breadth and quality • Widening access to financial services • A-synchrony (time-decoupled) • A - topy (location-decoupled)

3.15 BUSINESS APPLICATION SYSTEMS 3.15.9 Payment Systems: There are two types of parties involved in all payment systems, the issuers and the users. An issuer is an entity that operates the payment service. An issuer holds the items that the payments represent (e.g., cash held in regular bank accounts). The users of the payment service perform two main functions—making payments and receiving payments—and therefore can be described as a payer or a payee respectively.

3.15 BUSINESS APPLICATION SYSTEMS 3.15.9 Payment Systems (Electronic Money Model): The objective of electronic money systems is to emulate physical cash. An issuer attempts to do this by creating digital certificates, which are then purchased (or withdrawn) by the users, who then redeem (deposit) them with the issuer at a later date. In the interim, certificates can be transferred between users to trade for goods or services.

3.15 BUSINESS APPLICATION SYSTEMS 3.15.9 Payment Systems (Electronic Money Model): Some advantages of electronic money systems are: • The payer does not need to be online (generally) at the time of the purchase (since the electronic money can be stored on the payer’s computer). • The payer can have unconditional untraceability (albeit at the expense of lost interest on deposits).

3.15 BUSINESS APPLICATION SYSTEMS 3.15.9 Payment Systems (Electronic Checks Model): Electronic check systems model real-world checks quite well and are, thus, relatively simple to understand and implement. A user writes an electronic check, which is a digitally signed instruction to pay. Some advantages of electronic check systems are: • Easy to understand and implement • The availability of electronic receipts, allowing users to resolve disputes without involving the issuer • No need for payer to be online to create a payment

3.15 BUSINESS APPLICATION SYSTEMS 3.15.9 Payment Systems (Electronic Transfer Model): Electronic transfer systems are the simplest of the three payment models. The payer simply creates a payment transfer instruction, signs it digitally and sends it to the issuer. The issuer then verifies the signature on the request and performs the transfer. This type of system requires the payer to be online, but not the payee. Some advantages of electronic transfer systems are: • Easy to understand and implement • The payee does not need to be online, a considerable advantage in some circumstances (e.g., paying employee wages)

3.15 BUSINESS APPLICATION SYSTEMS 3.15.10 Integrated Manufacturing Systems: Integrated manufacturing systems (IMS) have a long history, and accordingly, there has been quite a diverse group of models and approaches. Some of the integrated manufacturing systems include bill of materials (BOM), BOM processing (BOMP), manufacturing resources planning (MRP), computer assised design (CAD), computer-integrated manufacturing (CIM), and manufacturing accounting and production (MAP).

3.15 BUSINESS APPLICATION SYSTEMS 3.15.11 Electronic Funds Transfer: As the Internet continues to transform commercial transactions, the method of payment is one bothersome concept that will take on an increasingly significant role in the relationship between seller and buyer. The underlying goal of the automated environment is to wring out costs inherent in the business processes. Electronic funds transfer (EFT) is the exchange of money via telecommunications without currency actually changing hands. In other words, EFT is the electronic transfer of funds between a buyer, seller and his/her respective financial institution.

3.15 BUSINESS APPLICATION SYSTEMS 3.15.12 Controls in an EFT: • All of the equipment and communication linkages are tested to effectively and reliably transmit and receive data. • Each party uses security procedures that are reasonably sufficient for affecting the authorized transmission of data and for protecting business records and data from improper access. • There are guidelines set for the receipt of data and to ensure that the receipt date and time for data transmitted are the date and time the data has been received.

3.15 BUSINESS APPLICATION SYSTEMS 3.15.12 Controls in an EFT: • Upon receipt of data, the receiving party will immediately transmit an acknowledgment or notification to communicate to the sender that a successful transmission occurred. • Data encryption standards are set. • Standards for unintelligible transmissions are set. • Regulatory requirements for enforceability of electronic data transmitted and received are explicitly stated.

3.15 BUSINESS APPLICATION SYSTEMS 3.15.13 Integrated Customer File: Integrated customer files provide details regarding all business relationships a customer maintains with an organization. The integration aids in customer analysis and marketing. An example of an integrated file is an integrated banking customer file. The file includes data regarding the customer loans, checking accounts, savings accounts and any certificates of deposit.

3.15 BUSINESS APPLICATION SYSTEMS 3.15.14 Office Automation: Currently, many offices use a variety of electronic devices and techniques to aid in the conduct of business. Word processors, automated spreadsheets and electronic mail are used daily in many offices. Local area networks link local offices and computers to facilitate the use of these technologies. Office automation devices and networks may contain sensitive data; however, access controls and security are frequently weak or nonexistent.

3.15 BUSINESS APPLICATION SYSTEMS 3.15.15 Automated Teller Machine: An automated teller machine (ATM) is a specialized form of the point-of-sale (POS) terminal that is designed for the unattended use by a customer of a financial institution. These customarily allow a range of banking and debit operations, especially financial deposits and cash withdrawals. ATMs are usually located in uncontrolled areas to facilitate easy access to customers after hours. This facility can be within a bank, across local banks and in banks outside a region. They are becoming known as retail EFT networks, transferring information and money over communication lines.

3.15 BUSINESS APPLICATION SYSTEMS 3.15.15 Automated Teller Machine: Recommended internal control guidelines for ATMs, apart from what has been provided for any EFT, include the following: • Written policies and procedures covering personnel, security controls, operations, disaster recovery credit and check authorization, floor limits, override, settlement, and balancing • Reconciliation of all general ledger accounts related to retail EFTs and review of exception items and suspense accounts • Procedures for PIN issuance and protection during storage • Procedures for the security of PINs during delivery and the restriction of access to a customer’s

3.15 BUSINESS APPLICATION SYSTEMS 3.15.15 Automated Teller Machine: • Systems should be designed, tested and controlled to preclude retrieval of stored PINs in any nonencrypted form. • Controls over plastic card procurement should be adequate with a written agreement between the card manufacturer and the bank that details control procedures and methods of resolution to be followed if problems occur. • Controls and audit trails of the transactions that have been made in the ATM.

3.15 BUSINESS APPLICATION SYSTEMS Audit of ATM: • Review measures to establish proper customer identification and maintenance of their confidentiality • Review file maintenance and retention system to trace transactions • Review exception reports to provide an audit trail • Review daily reconciliation of ATM machine transactions, including: – Review segregation of duties in the opening of ATM and recount of deposit – Review the procedures made for the retained cards • Review encryption key change management procedures

3.15 BUSINESS APPLICATION SYSTEMS 3.15.16 Cooperative Processing Systems: Cooperative processing systems are divided into segments so different parts may run on different independent computer devices. The system divides the problem into units that are processed in a number of environments and communicates the results among them to produce a solution to the total problem. The system must be designed to minimize and maintain the integrity of communication between the component parts and to use the most appropriate processor for each of the problem units.

3.15 BUSINESS APPLICATION SYSTEMS 3.15.17 Voice Response Ordering Systems: Voice response ordering systems are systems in which the user interacts with the computer over a telephone connection in response to verbal instructions given by the computer system. The customer communicates by using a tone-generating device, which might be the keypad of the telephone itself.

3.15 BUSINESS APPLICATION SYSTEMS 3.15.18 Purchase Accounting Systems: When financial transactions are processed, frequently they go through more than one system. In a department store, a sale is first processed in the sales accounting system, then processed by the accounts receivable system (if the purchase was by credit card) and, for either cash or credit sales, through the inventory system (when they are linked). That same sale might trigger the purchase accounting system to replace depleted inventory.

3.15 BUSINESS APPLICATION SYSTEMS 3.15.18 Purchase Accounting Systems: Most purchase accounting systems perform three basic accounting functions: Accounts payable processing—Recording transactions in the accounts payable records 2. Goods received processing—Recording details of goods received, but not yet invoiced 3. Order processing—Recording goods ordered, but not yet received The computer may be involved in each of these activities, and the extent to which they are computerized determines the complexity of the purchase accounting system.

3.15 BUSINESS APPLICATION SYSTEMS 3.15.19 Image Processing: Image processing is computer manipulation of images. Some of the many algorithms used in image processing include convolution (on which many others are based), fast Fourier transform (FFT), discrete cosine transform (DCT), thinning (or skeletonization), edge detection and contrast enhancement.

3.15 BUSINESS APPLICATION SYSTEMS 3.15.19 Image Processing: Most businesses that perform image processing obtain benefits from using the imaging system. Examples of potential benefits are: • Item processing (e.g., signature storage and retrieval) • Immediate retrieval via a secure optical storage medium • Increased productivity • Improved control over paper files • Reduced deterioration due to handling • Enhanced disaster recovery procedures

3.15 BUSINESS APPLICATION SYSTEMS 3.15.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

3.15 BUSINESS APPLICATION SYSTEMS 3.15.20 Artificial Intelligence and Expert Systems: Artificial intelligence fields include, among others: • Expert systems • Natural and artificial (such as programming) languages • Neural networks • Intelligent text management • Theorem proving • Abstract reasoning • Pattern recognition • Voice recognition • Problem solving • Machine translation of foreign languages

3.15 BUSINESS APPLICATION SYSTEMS 3.15.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. Investments in BI technology can be applied to enhance understanding of a wide range of business questions.

3.15 BUSINESS APPLICATION SYSTEMS 3.15.21 Business Intelligence: Some typical areas in which BI is applied for measurement and analysis purposes include: • Process cost, efficiency and quality • Customer satisfaction with product and service offerings • Customer profitability, including determination of which attributes are useful predictors of customer profitability • Staff and business unit achievement of key performance indicators • Risk management, e.g., by identifying unusual transaction patterns and accumulation of incident and loss statistics

3.15 BUSINESS APPLICATION SYSTEMS 3.15.21 Business Intelligence Governance: To maximize the value an organization obtains from its BI initiatives, an effective BI governance process needs to be in place. An important part of the governance process involves determining which BI initiatives to fund, what priority to assign to initiatives and how to measure their return on investment. This is particularly important, as the investment needed to build BI infrastructure, such as a data warehouse (DW), is considerable. Additionally, the scope and complexity of an organization wide DW means that, realistically, it must be built in stages.

3.15 BUSINESS APPLICATION SYSTEMS 3.15.22 Decision Support Systems: 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 semi structured decision-making tasks typically for business purposes.

3.15 BUSINESS APPLICATION SYSTEMS 3.15.22 Decision Support Systems: Typical information that a decision support application might gather and present would be: • Comparative sales figures between one week and the next • Projected revenue figures based on new product sales assumptions • The consequences of different decision alternatives, given past experience in the described context

3.15 BUSINESS APPLICATION SYSTEMS DSS FrameWorks: 1. The degree of structure in the decision process being supported 2. The management level at which decision making takes place

3.15 BUSINESS APPLICATION SYSTEMS DSS FrameWorks: This framework also portrays all information system efforts as addressing distinct types of problems, depending on the above two factors. The management-level dimension is broken into three parts: 1. Operational control 2. Management control 3. Strategic planning The decision-structure dimension is also broken into three parts: 1. Structured 2. Semi structured 3. Unstructured

3.15 BUSINESS APPLICATION SYSTEMS Risk Factors: Developers should be prepared for eight implementation risk factors: 1. Nonexistent or unwilling users 2. Multiple users or implementers 3. Disappearing users, implementers or maintainers 4. Inability to specify purpose or usage patterns in advance 5. Inability to predict and cushion impact on all parties 6. Lack or loss of support 7. Lack of experience with similar systems 8. Technical problems and cost-effectiveness issues

3.15 BUSINESS APPLICATION SYSTEMS Customer Relationship Management: The emerging customer driven business trend is around the wants and needs of the customers. With the customer’s expectations constantly raising, these objectives are becoming more difficult to achieve. This emphasizes the importance of focusing on information relating to transaction data, preferences, purchase patterns, status, contact history, demographic information and service trends of customers, rather than on products.

3.15 BUSINESS APPLICATION SYSTEMS Customer Relationship Management: It is possible to distinguish between operational and analytical CRM. Operational CRM is concerned with maximizing the utility of the customer’s service experience, while also capturing useful data about the customer interaction. Analytical CRM seeks to turn the data an organization has captured about its customers and their interactions with the organization into information that allows greater value to be obtained from the customer base. Among uses of analytical CRM are increasing customer product holdings or “share of customer wallet,” moving customers into higher margin products, moving customers to lower cost service channels, increasing marketing success rates, and making pricing decisions.

3.15 BUSINESS APPLICATION SYSTEMS Supply Chain Management: SCM is about linking the business processes between the related entities, e.g., the buyer and the seller. The link is provided to all the connected areas, such as managing logistics and the exchange of information, services and goods between supplier, consumer, warehouse, wholesale/retail distributors and the manufacturer of goods.

3.16 Chapter 3 Case Study A major retailer asked the IS auditor to review their readiness for complying with credit card company requirements for protecting cardholder information. The IS auditor subsequently learned the following information. The retailer uses wireless point-of-sale registers that connect to application servers located at each store. These registers use wired equivalent protection (WEP) encryption. The application server, usually located in the middle of the store’s customer service area, forwards all sales data over a frame relay network to database servers located at the retailer’s corporate headquarters, and using strong encryption over an Internet virtual private network (VPN) to the credit card processor for approval of the sale. Corporate databases are located on a protected screened subset of the corporate local area network. Additionally, weekly aggregate sales data by product line is copied from the corporate databases to magnetic media and mailed to a third party for analysis of buying patterns. It was noted that the retailer’s database software has not been patched in over two years. This is because vendor support for the database package was dropped due to management’s plans to eventually upgrade to a new ERP system.

1. Which of the following would present the MOST significant risk to the retailer? A. Wireless point-of-sale registers use WEP encryption. B. Databases patches are severely out-of-date. C. Credit cardholder information is sent over the Internet. D. Aggregate sales data are mailed to a third party. PRACTICE QUESTIONS CASE STUDY

2. Based on the case study, which of the following controls would be the MOST important to implement? A. Store application servers should be located in a secure area. B. Point-of-sale registers should use two-factor authentication. C. Wireless access points should use MAC address filtering. D. Aggregate sales data sent offsite should be encrypted. PRACTICE QUESTIONS CASE STUDY

Chap3 2007 Cisa Review Course

More Related Content

What's hot (20)

Viewers also liked (18)

Similar to Chap3 2007 Cisa Review Course (20)

More from Desmond Devendran (20)

Recently uploaded (20)

Chap3 2007 Cisa Review Course

Editor's Notes