CISA Information Systems Acquisition, Development and Implementation: 60 practice questions

12 of the 60 Information Systems Acquisition, Development and Implementation questions in the Certsqill CISA bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for CISA? Take the free 5-min readiness check →

1. To define and enforce standardized project management: Which of the following BEST describes the primary purpo

1. To define and enforce standardized project management methodologies, templates, and reporting across the project portfolio ✓

   Correct. A PMO's core function is to institutionalize consistent project management practices, tooling, and portfolio-level reporting so projects are governed and comparable, rather than each being run ad hoc.
2. To approve each project's business case, authorize its funding, and release the capital budget before any project work is permitted to begin

   Incorrect. Approving business cases and releasing funding is the role of the project steering committee or sponsor; the PMO supports and monitors execution, it does not authorize the investment.
3. To design the technical architecture, choose the technology stack, and write the application code for each project in the portfolio

   Incorrect. Solution design and development are performed by architects and development teams; the PMO is a governance and support function, not a delivery/build function.
4. To perform independent post-implementation audits of completed projects

   Incorrect. Independent post-implementation audits are performed by internal audit to preserve objectivity; a PMO that audited its own projects would lack independence.

A PMO exists to standardize and oversee how projects are managed across the portfolio, not to fund, build, or audit them.

2. Providing overall direction: Which responsibility is MOST appropriately assigned to this committee?

1. Providing overall direction, approving scope and budget, and ensuring the program stays aligned with organizational objectives ✓

   Correct. A steering committee provides high-level governance: it sets direction, approves major scope/budget changes, and confirms the program continues to serve business goals.
2. Managing the day-to-day tasks, maintaining the schedule, and running the issue and risk logs for the program on a daily operational basis

   Incorrect. Day-to-day management is the project manager's responsibility; a steering committee governs at the milestone/decision level, not the task level.
3. Producing the detailed technical design of the records database

   Incorrect. Detailed design is done by architects and developers; a governance body does not perform technical build work.
4. Executing user acceptance testing of the delivered software

   Incorrect. UAT is executed by business users/testers; the committee may review UAT results as a go/no-go input but does not perform the testing.

The steering committee governs: direction, scope/budget approval, and business alignment, not daily management or technical work.

3. The time required for cumulative net cash inflows: What does the payback period measure?

1. The time required for cumulative net cash inflows from the project to recover the initial investment ✓

   Correct. Payback period is simply how long it takes for the project's cumulative net cash inflows to equal the money originally spent.
2. The percentage return the project earns per year on the invested capital

   Incorrect. That describes return on investment (ROI) or accounting rate of return, which is expressed as a percentage, not a time span.
3. The present value of the project's expected future cash flows minus the initial capital investment outlay

   Incorrect. That is net present value (NPV), which discounts future cash flows to today's value; payback ignores the time value of money.
4. The discount rate at which the project's net present value equals zero

   Incorrect. That is the internal rate of return (IRR), a rate, not a recovery time.

Payback period = how long until cumulative cash inflows recover the initial outlay.

4. Design: Which phase immediately follows the requirements definition phase?

1. Design ✓

   Correct. In waterfall, requirements are frozen and the next phase is design, where those requirements are translated into system and detailed technical specifications before any coding begins.
2. Development (coding)

   Incorrect. Coding cannot properly begin until the design phase has translated requirements into specifications; jumping straight to coding skips a required waterfall stage.
3. Testing

   Incorrect. Testing occurs after development; it verifies built software against the design and requirements, so it cannot immediately follow requirements.
4. Feasibility study

   Incorrect. The feasibility study precedes requirements definition; it is not a later phase.

In waterfall, the sequence is feasibility, requirements, then design, then development, testing, and implementation.

5. The Product Owner: Who is primarily responsible for prioritizing the product backlog to maximize the value del

1. The Product Owner ✓

   Correct. The Product Owner owns and orders the product backlog, deciding what work delivers the most value and in what priority the team should tackle it.
2. The Scrum Master

   Incorrect. The Scrum Master facilitates the process and removes impediments; they coach the team but do not own backlog priority.
3. The Development Team collectively

   Incorrect. The Development Team decides how much backlog it can pull into a sprint and how to build it, but priority (the 'what' and its order) is set by the Product Owner.
4. The project sponsor

   Incorrect. The sponsor funds the initiative and sets high-level objectives but is not a Scrum role and does not manage the backlog day to day.

In Scrum, the Product Owner prioritizes the product backlog to maximize value.

6. To determine whether the proposed solution is technically: What is the PRIMARY purpose of this study?

1. To determine whether the proposed solution is technically, economically, and operationally viable before significant resources are committed ✓

   Correct. A feasibility study assesses whether a proposed system can realistically be delivered and is worth pursuing across technical, economic, operational (and often legal/schedule) dimensions, informing the go/no-go decision.
2. To produce the detailed technical design, the physical data model, and the interface specifications of the new policy-administration platform before build

   Incorrect. Detailed design happens later in the SDLC after the project is approved; feasibility precedes and informs that commitment.
3. To select the specific vendor and negotiate the final contract

   Incorrect. Vendor selection and contracting follow once the project is deemed feasible and approved; feasibility is about whether to proceed at all.
4. To train end users on the new platform before deployment

   Incorrect. Training is an implementation-phase activity, far downstream of the initial viability assessment.

A feasibility study establishes whether a proposed system is viable (technical, economic, operational) before major resources are spent.

7. Activities on the critical path: To minimize the risk of delaying the project's completion date, on which acti

1. Activities on the critical path, which have zero float and directly determine the project end date ✓

   Correct. Critical-path activities have no slack; any slippage in them pushes out the whole project, so they warrant the closest monitoring to protect the completion date.
2. The activities carrying the largest budget allocation, on the assumption that costlier work poses the greatest threat to the deadline

   Incorrect. Cost magnitude does not determine schedule impact; a costly activity with ample float can slip without delaying completion, while a cheap zero-float task cannot.
3. Activities with the most float, because their large scheduling flexibility gives the project manager the greatest room to recover lost time

   Incorrect. High-float activities can absorb delay without affecting the end date, so they are the least schedule-critical, this is the opposite of the correct focus.
4. Activities assigned to the largest number of team members

   Incorrect. Team size does not indicate schedule sensitivity; an activity with many people can still have float, and a solo task can be on the critical path.

Focus on critical-path activities, they have zero float, so any delay in them delays the whole project.

8. The project is behind schedule but under budget: Which statement BEST describes the project's status?

1. The project is behind schedule but under budget for the work performed so far ✓

   Correct. SPI below 1.0 means less work has been completed than planned (behind schedule), while CPI above 1.0 means the completed work cost less than budgeted (under budget).
2. The project is ahead of schedule but running over budget for the volume of work performed to date

   Incorrect. This reverses both indices; SPI < 1.0 is behind schedule, not ahead, and CPI > 1.0 is under budget, not over.
3. The project is exactly on schedule and precisely on budget, with both performance indices sitting at the neutral baseline value

   Incorrect. On-schedule/on-budget would require both indices to equal 1.0; neither does here.
4. The project is behind schedule and also over budget for the work completed so far, so both indices are unfavorable

   Incorrect. The behind-schedule half is right, but CPI of 1.10 indicates under budget, not over; over budget would be CPI < 1.0.

SPI 0.85 = behind schedule; CPI 1.10 = under budget. So behind schedule but under budget.

9. Option Meridian: On financial grounds, which option should the utility select and why?

1. Option Meridian, because among mutually exclusive positive-NPV options the one with the higher NPV adds the most value to the organization ✓

   Correct. When choosing between mutually exclusive projects, the NPV rule is to pick the highest positive NPV, as NPV directly measures the net value added in today's terms.
2. Option Vireo, because a lower NPV means lower risk exposure

   Incorrect. NPV magnitude does not represent risk; risk is captured in the discount rate and separate risk analysis. A lower NPV is simply less value added, not inherently safer.
3. Neither, because a positive NPV alone is insufficient to justify any investment

   Incorrect. A positive NPV means the project is expected to add value after covering the cost of capital; that is precisely the financial justification to proceed.
4. Either option, because both projects have a positive NPV over the same horizon and are therefore financially equivalent choices for the utility

   Incorrect. Positive NPV makes both acceptable in isolation, but they are mutually exclusive, so the higher-NPV option is preferred, they are not equivalent.

For mutually exclusive positive-NPV projects, choose the highest NPV, it adds the most value.

10. Ignore the time value of money and all cash flows: An IS auditor reviewing the business case is MOST concerned

1. Ignore the time value of money and all cash flows occurring after the payback point ✓

   Correct. Payback's two structural weaknesses are that it does not discount cash flows and it stops counting once the initial outlay is recovered, so it can favor short-term projects and overlook long-term value or later costs.
2. Overstate the project's risk by discounting its future cash flows far too heavily against the applied hurdle rate

   Incorrect. Payback does not discount cash flows at all, so it cannot overstate risk through excessive discounting; that concern would apply to a mis-set NPV/IRR discount rate.
3. Require formal external audit sign-off on the metric before it can be relied upon in the business case

   Incorrect. No standard mandates external sign-off to use payback; the concern is analytical soundness, not an approval formality.
4. Prevent the project from ever being compared against competing alternative investments on any basis

   Incorrect. Payback can still be compared across options; the problem is that it is an incomplete basis for comparison, not that comparison is impossible.

Payback ignores the time value of money and any cash flows after the payback point, so it is a weak sole basis for a decision.

11. An incompletely tested prototype is promoted to production: Which risk should an IS auditor be MOST alert to w

1. An incompletely tested prototype is promoted to production with weak documentation and controls because it 'already works' ✓

   Correct. The classic prototyping risk is that the quickly built prototype, focused on look and feel, is adopted as the production system without adequate controls, security, error handling, and documentation.
2. Requirements are frozen too early in the lifecycle, preventing any further user feedback once the first prototype has been demonstrated

   Incorrect. That is a criticism of rigid waterfall; prototyping's whole point is to elicit feedback iteratively, so requirements are not frozen early.
3. Users are entirely excluded from the development process

   Incorrect. Prototyping is highly user-involved; low user engagement is not its characteristic weakness.
4. The methodology forbids any changes once a prototype is shown to users

   Incorrect. Prototyping embraces change between iterations; it does not lock the design after a demo.

Prototyping's key risk: an under-controlled, poorly documented prototype gets pushed into production because it appears to work.

12. Segregation of duties is weakened: What should be the IS auditor's PRIMARY concern, and the BEST compensating

1. Segregation of duties is weakened; the best compensating control is enforced, automated pipeline controls (peer code review, automated approval gates, and immutable logging) that no single person can bypass ✓

   Correct. Merging development and deployment erodes traditional SoD, so assurance shifts to controls embedded in the pipeline, mandatory peer review, automated gates, and tamper-evident logs, that prevent any one person from unilaterally moving code to production.
2. Developers will write lower-quality code; the best control is to lengthen the release cycle back to quarterly

   Incorrect. Code quality is not the primary governance concern, and forcing slow releases defeats DevOps' purpose rather than addressing the actual control gap (SoD).
3. Automated testing is impossible in DevOps; the best control is to add a manual test team

   Incorrect. DevOps relies heavily on automated testing, the premise is false, so the recommended control does not address the real risk.
4. Version control cannot be maintained; the best control is to forbid frequent commits

   Incorrect. DevOps depends on robust version control and frequent commits; restricting them contradicts the model and misses the SoD concern.

DevOps blurs dev/ops SoD; restore assurance with automated pipeline controls, peer review, approval gates, and immutable logging, no single person can bypass.

Other CISA domains

• Information Systems Operations and Business Resilience — 129 questions →
• Protection of Information Assets — 129 questions →
• Information Systems Auditing Process — 89 questions →
• Governance and Management of IT — 89 questions →
• All 496 CISA questions →