01-30 CISA Domain III Questions Answer and Explanation

The audit trail should be activated during the implementation of the application.

Following implementation, a cost-benefit analysis or return on investment should be reperformed to verify that the original business case benefits are delivered.

User acceptance testing should be performed prior to the implementation (perhaps during the development phase), not after the implementation.

While updating the enterprise architecture diagrams is a good practice, it would not normally be part of a post implementation review.

In many cases, the test environment is not configured with the same access controls that are enabled in the production environment. For example, programmers may have privileged access to the test environment (for testing), but not to the production environment. If the test environment does not have adequate access control, the production data are subject to risk of unauthorized access and/or data disclosure. This is the most significant risk of the choices listed.

The accuracy of data used in the test environment is not of significant concern as long as these data are representative of the production environment.

Hardware in the test environment should mirror the production environment to ensure that testing is reliable. However, this does not relate to the risk from using live data in a test environment. This is not the correct answer because it does not relate to the risk presented in the scenario.

Using production data in the test environment does not cause test results to be inaccurate. If anything, using production data improves the accuracy of testing processes, because the data most closely mirror the production environment. In spite of that fact, the risk of data disclosure or unauthorized access in the test environment is still significant and, as a result, production data should not be used in the test environment. This is especially important in a healthcare organization where patient data confidentiality is critical and privacy laws in many countries impose strict penalties on misuse of these data.

Total cost of ownership of the application is important to understand the resource and budget requirements in the short and long term; however, decisions should be based on benefits realization from this investment. Therefore, return on investment (ROI) is the most important consideration.

The resources required for implementation of the application are an important consideration; however, decisions should be based on benefits realization from this investment. Therefore, ROI should be carefully considered.

The proposed ROJ benefits, along with targets or metrics that can be measured, are the most important aspects of a business case. While reviewing the business case, it should be verified that the proposed ROJ is achievable, does not make unreasonable assumptions and can be measured for success. (Benefits realization should look beyond project cycles to longer-term cycles that consider the total benefits and total costs throughout the life of the new system.)

The cost and complexity of security requirements are important considerations, but they need to be weighed against the proposed benefits of the application. Therefore, ROI is more important.

A characteristic of prototyping is its emphasis on reports and screens, but it does not have an adverse effect on change control.

Changes in requirements and design happen so quickly that they are seldom documented or approved.

Lack of integrated tools is a characteristic of prototyping, but it does not have an adverse effect on change control.

A characteristic of prototyping is its iterative nature, but it does not have an adverse effect on change control.

Unit testing references the detailed design of the system and uses a set of cases that focus on the control structure of the procedural design to ensure that the internal operation of the program performs according to specification.

System testing relates a,series of tests by the test team or system maintenance staff to ensure that the modified program interacts correctly with other components. System testing references the functional requirements of the system.

Acceptance testing determines whether the solution meets the requirements of the business and is performed after system staff has completed the initial system test. This testing includes both quality assurance testing and user acceptance testing, although not combined.

Integration testing evaluates the connection of two or more components that pass information from one area to another. The objective is to use unit-tested modules, thus building an integrated structure according to the design.

A Gantt chart is a simple project management tool and would help with the prioritization requirement, but it is not as effective as program evaluation review technique (PERT).

The PERT method works on the principle of obtaining project timelines based on project events for three likely scenarios-worst, best and normal. The timeline is calculated by a predefined formula and identifies the critical path, which identifies the key activities that must be prioritized.

Earned value analysis is a technique to track project cost versus project deliverables but does not assist in prioritizing tasks.

Function point analysis measures the complexity of input and output and does not help to prioritize project activities.

The fact that a training program does not exist is only be a minor concern for the IS auditor.

When one application is expanded to multiple departments, it is important to ensure the mapping between the process owner and system functions. The absence of a defined process owner, may cause issues with monitoring or authorization controls.

The allocation method of application usage cost is of less importance.

The fact that multiple application owners exist is not a concern for an IS auditor as long as process owners have been identified.

A console log printout is not the best because it does not record activity from a specific terminal.

The user error report lists only input that resulted in an edit error and does not record improper user input.

The transaction journal records all transaction activity, which then can be compared to the authorized source documents to identify any unauthorized input.

An automated suspense file listing lists only transaction activity where an edit error occurred.

A program evaluation review technique (chart will help determine project duration once all the activities and the work involved with those activities are known.

Object-oriented system development is the process of solution specification and modeling but will not assist in calculating project duration.

Rapid application development is a methodology that enables organizations to develop strategically important systems faster while reducing development costs and maintaining quality.

Function point analysis is a technique for determining the size of a development task based on the number of function points. Function points are factors such as inputs, outputs, inquiries and logical internal files. While this will help determine the size of individual activities, it will not assist in determining project duration because there are many overlapping tasks.

The prototyping application development technique reduces the time to deploy systems primarily by using faster development tools that allow a user to see a high-level view of the workings of the proposed system within a short period of time. The use of anyone development methodology will have a limited impact on the success of the project.

Compliance with applicable external requirements has an impact on the implementation success, but the impact is not as significant as the impact of the overall organizational environments.

The overall organizational environment has the most significant impact on the success of applications systems implemented. This includes the alignment between IT and the business, the maturity of the development processes and the use of change control and other project management tools.

The software reengineering technique is a process of updating an existing system by extracting and reusing design and program components. This is used to support major changes in the wayan organization operates. Its impact on the success of the application systems that are implemented is small compared with the impact of the overall organizational environment.

Independence can be compromised if the IS auditor advises on the adoption of specific application controls.

The review of the test cases will facilitate the objective of a successful migration and ensure that proper testing is conducted. An IS auditor can advise as to the completeness of the test cases.

Advising the project manager on how to increase the efficiency of the migration may compromise the IS auditor's independence.

Independence can be compromised if the IS auditor were to audit the estimate of future expenses used to support a business case for management approval of the project.

Controls will often affect productivity and performance; however,this must be balanced against the benefit obtained from the implementation of the control.

The most important reason for a control is to mitigate a risk-and the selection of a control is usually based on a cost-benefit analysis, not on selecting just the least expensive control.

A good control environment will include preventive, detective and corrective controls.

The purpose of a control is to mitigate a risk; therefore, the primary consideration when selecting a control is that it effectively mitigates an identified risk. When designing controls, it is necessary to consider all of the aspects in choices A through D. In an ideal situation, controls that address all of these aspects would be the best controls. Realistically, it may not be possible to design them all and the cost may be prohibitive; therefore, it is necessary to consider the controls related primarily to the treatment of existing risk in the organization.

An ITF creates a fictitious entity in the database to process test transactions simultaneously with live input. Its advantage is that periodic testing does not require separate test processes. Careful planning is necessary, and test data must be isolated from production data.

The ITF is based on the integration of test data into the normal process flow,so test data is still required.

An ITF does validate the correct operation of a transaction in an application, but it does not ensure that a system is being operated correctly.

The integrated test facility (ITF) tests a test transaction as if it were a real transaction and validates that transaction processing is being done correctly. It is not related to reviewing the source of a transaction.

The costs for a SaaS solution should be fixed as a part of the services contract and considered in the business case presented to management for approval of the solution.

Software As a service (SaaS) is provisioned on a usage basis and the number of users is monitored by the SaaS provider;therefore,there should be no risk of non compliance with software license agreements.

The risk that can be most likely encountered in a SaaS environment is speed and availability issues, because SaaS relies on the Internet for connectivity.

The open design and Internet connectivity allow most SaaS to run on virtually any type of hardware.

A configuration management database (which stores the configuration details for an organization's IT systems) is an important tool for IT service delivery and,in particular,change management.It may provide information that would influence the prioritization of projects but is not designed for that purpose.

Portfolio management is designed to assist in the definition, prioritization, approval and running of a set of projects within a given organization. These tools offer data capture, workflow and scenario planning functionality, which can help identify the optimum set of projects (from the full set of ideas) to take forward within a given budget.

A capability maturity model (CMM) would not help determine the optimal portfolio of capital projects because it is a means of assessing the relative maturity of the IT processes within an organization: running from Level 0 (Incomplete-Processes are not implemented or fail to achieve their purpose) to Level 5 (Optimizing-Metrics are defined and measured, and continuous improvement techniques are in place).

The project management body of knowledge is a methodology for the management and delivery of projects. It offers no specific guidance or assistance in optimizing a project portfolio.

Because the business case was not established, it is likely that the business rationale, risk and risk mitigation strategies for outsourcing the application development were not fully evaluated and the appropriate information was not provided to senior management for formal approval. This situation presents the biggest risk to the organization.

If the source code is held by the provider and not provided to the organization, the lack of source code escrow presents a risk to the organization; however, the risk is not as consequential as the lack of a business case.

The lack of the right to audit clause presents a risk to the organization; however, the risk is not as consequential as the lack of a business case.

The lack of change management procedures presents a risk to the organization, especially with the possibility of extraordinary charges for any required changes; however, the risk is not as consequential as the lack of a business case.

By evaluating the organization's development projects against the CMM, an IS auditor determines whether the development organization follows a stable, predictable software development process.

The capability maturity model (CMM) does not evaluate technical processes such as programming efficiency. _

Although the likelihood of success should increase as the software processes mature toward the optimization level, mature processes do not guarantee a reliable product.

The CMM does not evaluate security requirements or other application controls.

The stop point is used for project control but not to create an artificial fixed point that requires the design of the project to cease,

Projects often tend to expand, especially during the requirements definition phase. This expansion often grows to a point where the originally anticipated cost-benefits are diminished because the cost of the project has increased. When this occurs, it is recommended that the project be stopped or frozen to allow a review of all of the cost-benefits and the payback period.

The stop point is intended to provide greater control over changes but not to prevent them.

A stop point is used to control requirements, not systems design.

Rarely do hardware limitations affect the usability of the project as long as the requirements were correctly documented at the beginning of the project.

Although changing user needs has an effect on the success or failure of many projects, the core problem is usually a lack of getting the initial requirements correct at the beginning of the project.

Projects may fail as the needs of the users increase; however, this can be mitigated through better change control procedures.

Lack of adequate user involvement, especially in the system's requirements phase, will usually result in a system that does not fully or adequately address the needs of the user. Only users can define what their needs are and, therefore, what the system should accomplish.

Although the project is on time and budget, there may be problems with the project plan because considerable amounts of unplanned overtime have been required.

It is possible that the programmers are trying to take advantage of the time system, but if the overtime has been required to keep the project on track it is more likely that the timelines and expectations of the project are unrealistic.

There is a possibility that the project manager has hidden some costs to make the project look better; however, the real problem may be with whether the project plan is realistic, not just the accounting.

Although the dates on which key projects are completed are important, there may be issues with the project plan if an extraordinary amount of unplanned overtime is required to meet those dates. In most cases, the project plan is based on a certain number of hours, and requiring programmers to work considerable overtime is not a good practice. Although overtime costs may be an indicator that something is wrong with the plan, in many organizations, the programming staff may be salaried, so overtime costs may not be directly recorded.

The problem with testing only functional requirements is that nonfunctional requirement areas, such as usability and security, which are important to the overall quality of the system, are ignored.

Retesting only defect fixes has a considerable risk that it will not detect instances in which defect fixes may have caused the system to regress (i.e., introduced errors in parts of the system that were previously working correctly). For this reason, it is a good practice to undertake formal regression testing after defect fixes have been implemented.

Increasing the efficiency of testing by automating test execution is a good idea. However, by itself, this approach does not ensure the appropriate targeting of test coverage and so is not as effective an alternative.

The idea is to maximize the usefulness of testing by concentrating on the most important aspects of the system and on the areas where defects represent the greatest risk to user acceptance. A further extension of this approach is to also consider the technical complexity of requirements, because complexity tends to increase the likelihood of defects.

Creation Of a test deck from Production Data does not require specialized knowledge,so this is not a concern.

A primary risk of using production data in a test deck is that not all transactions or functionality may be tested if there are no data that meet the requirement.

The presence of production data in a test environment is not a concern if the sensitive elements have been scrubbed.

The risk of a project running over budget is always a concern, but it is not related to the practice of using production data in a test environment.

The first concern of an IS auditor is to ensure that the proposal meets the needs of the business. This should be established by a clear business case.

Compliance with security standards is essential, but it is too early in the procurement process for this to be an IS auditor's first concern.

Having users involved in the implementation process is essential, but it is too early in the procurement process for this to be an IS auditor's first concern.

Meeting the needs of the users is essential, and this should be included in the business case presented to management for approval.

Program Logic specification is a very technical task that is normally performed by a programmer. This could introduce a segregation of duties issue. . .

Performance tuning also requires high levels of technical skill and will not be effectively accomplished by a user. This could introduce a segregation of duties issue.

System configuration is usually too technical to be accomplished by a user and this situation could create security issues. This could introduce a segregation of duties issue.

A user can test program output by checking the program input and comparing it with the system output. This task, although usually done by the programmer, can also be done effectively by the user.

Parallel operation is designed to provide assurance that a new system meets its functional requirements. This is the safest form of system conversion testing because, if the new system fails, the old system is still available for production use. In addition, this form of testing allows the application developers and administrators to simultaneously run operational tasks (e.g., batch jobs and backups) on both systems, to ensure that the new system is reliable before unplugging the old system.

Parallel operation provides a high level of assurance that the new system functions properly compared to the old system. Parallel operation is generally expensive and does not provide a cost savings over most other testing approaches. In many cases, parallel operation is the most expensive form of system testing due to the need for dual data entry, dual sets of hardware, dual maintenance and dual backups-it is twice the amount of work as running a production system and, therefore, costs more time and money.

Increased resiliency during parallel processing is a legitimate outcome from this scenario, but the advantage it provides is temporary and minor, so this is not the correct answer.

Hardware compatibility should be determined and tested much earlier in the conversion project and is not an advantage of parallel operation. Compatibility is generally determined based on the application's published specifications and on system testing in a lab environment. Parallel operation is designed to test the application's effectiveness and integrity of application data, not hardware compatibility. In general, hardware compatibility relates more to the operating system level than to a particular application. Although new hardware in a system conversion must be tested under a real production load, this can be done without parallel systems.

Processing controls should be implemented as close as possible to the point of data entry. Limit checks are one type of input validation check that provides a preventive control to ensure that invalid data cannot be entered because values must fall within a predetermined limit.

A sample of transactions may be recalculated manually to ensure that processing is accomplishing the anticipated task. Recalculations are performed after the output phase.

Run-to-run totals provide the ability to verify data values through the stages of application processing. Run-to-run total verification ensures that data read into the computer were accepted and then applied to the updating process. Run-to-run totals are performed after the output phase.

Reconciliation of file totals should be performed on a routine basis. Reconciliations may be performed through the use of a manually maintained account, a file control record or an independent control file. Reconciliations are performed after the output phase.

User management assumes ownership of the project and resulting system, allocates qualified representatives to the team and actively participates in system requirements definition, acceptance testing and user training. User management should review and approve system deliverables as they are defined and accomplished, or implemented.

Quality assurance staff review results and deliverables within each phase, and at the end of each phase confirm compliance with standards and requirements. The timing of reviews depends on the system development life cycle, the impact of potential deviation methodology used, the structure and magnitude of the system and the impact of potential deviation.

A project steering committee provides overall direction, ensures appropriate representation of the major stakeholders in the project's outcome, reviews project progress regularly and holds emergency meetings when required. A project steering committee is ultimately responsible for all deliverables, project costs and schedules.

Senior management demonstrates commitment to the project and approves the necessary resources to complete the project. This commitment from senior management helps ensure involvement by those who are needed to complete the project.

A lack of testing is always a risk; however, in this case, the new payroll system is a subsystem of an existing commercially available (and therefore probably well-tested) system.

The most significant risk after a payroll system conversion is loss of data integrity and not being able to pay employees in a timely and accurate manner or have records of past payments. As a result, maintaining data integrity and accuracy during migration is paramount.

Setting Up the new system, including access permissions and payroll data, always presents some level of risk; however,the greatest risk is related to the migration of data from the old system to the new system

Undocumented changes (leading to scope creep) are a risk, but the greatest risk is the loss of data integrity when migrating data from the old system to the new system.

Alpha testing is the testing stage just before beta testing. Alpha testing is typically performed by programmers and business analysts, instead of users. Alpha testing is used to identify bugs or glitches that can be fixed before beta testing begins with external users.

White box testing is performed much earlier in the software development life cycle than alpha or beta testing. White box testing is used to assess the effectiveness of software program logic, where test data are used to determine procedural accuracy of the programs being tested. In other words, does the program operate the way it is supposed to at a functional level? White box testing does not typically involve external users.

Regression Testing is the process of re-running a portion of a test scenario to ensure that changes or corrections have not introduced more errors. In other words, the same tests are run after multiple successive program changes to ensure that the "fix" for one problem did not "break" another part of the program. Regression Testing is not the last stage of testing and does not typically involve external users.

Beta testing is the final stage of testing and typically includes users outside of the development area. Beta testing is a form of user acceptance testing and generally involves a limited number of users who are external to the development effort.

Project procurement management is defined as the processes required to acquire goods and services from outside the performing organization. Although purchasing goods and services that are too expensive can cause budget overruns, in this case the key to the question is that implemented functionality is greater than what was required, which is more likely related to project scope.

Project risk management is defined as the processes concerned with identifying, analyzing and responding to project risk. Although the budget overruns mentioned above represent one form of project risk, they appear to be caused by implementing too much functionality, which relates more directly to project scope.

Because the implemented functionality is greater than what was required, the most likely cause of the budget issue is failure to effectively manage project scope. Project scope management is defined as the processes required to ensure that the project includes all of the required work, and only the required work, to complete the project.

Project time management is defined as the processes required to ensure timely completion of the project. The issue noted in the question does not mention whether projects were completed on time, so this is not the most likely cause.