4.1 Information Systems Acquisition, Development, and Implementation Overview

What Domain 3 Tests

Domain 3 — Information Systems Acquisition, Development, and Implementation is approximately 12% of the CISA exam following the August 2024 content-outline update, which reduced it from 18%. Despite the smaller weighting, it is conceptually dense: it covers how an organization plans, justifies, acquires, builds, tests, migrates, and reviews information systems, and where the IS auditor inserts independent assurance.

The defining CISA mindset is that the System Development Life Cycle (SDLC) is a control and risk-management framework, not a software-engineering method. ISACA does not test you on writing code; it tests whether the right controls exist at the right phase, whether evidence of those controls is retained, and whether risk is managed as the system moves from idea to production.

The classic SDLC phases the auditor walks through are feasibility, requirements definition, design, development/configuration, testing, implementation (go-live), and post-implementation review, followed by maintenance. Each phase produces deliverables the auditor uses as evidence: an approved feasibility study, a signed requirements specification, design documents, test plans and results, conversion reconciliations, and sign-offs.

A recurring exam theme is timing of detection — a control weakness or requirement defect is dramatically cheaper to correct in requirements or design than after the system is live, which is why early, independent auditor involvement is encouraged.

Project Justification: Business Case and Feasibility

Every project should begin with a business case — a documented justification linking the proposed system to a measurable business benefit, cost, and risk. The business case is the baseline against which benefits realization is later measured. If a project has no business case, the auditor cannot tell whether it delivered value, so its absence is a control weakness.

A feasibility study then tests whether the proposal is achievable. CISA candidates should recognize the standard dimensions:

The business case and feasibility study together inform the go/no-go decision. The auditor verifies that this decision was made by an authorized governance body — typically a steering committee — and not unilaterally by the project team or a single sponsor. A weak or absent feasibility study is a leading cause of failed projects: organizations commit funds before confirming the solution is technically achievable, economically justified, and operationally supportable.

The auditor therefore treats the feasibility study and business case as the foundational controls of the whole life cycle, because every later decision inherits their assumptions.

Project Governance and the Steering Committee

Project governance assigns accountability. The IT/project steering committee sets priorities, approves budgets, monitors progress, and resolves cross-functional conflicts. It is a senior, business-led body — its presence shows that IT investment is aligned to business strategy rather than driven solely by technologists.

Key roles the exam expects you to distinguish:

• Sponsor / business owner — owns the business case and accepts the system (signs off UAT).
• Project manager — plans, schedules, and controls scope, cost, and time.
• Steering committee — authorizes and oversees at the portfolio/project level.
• Quality assurance — independent of development, verifies process adherence.
• IS auditor — provides independent assurance and control advice.

The Auditor's Role Across the SDLC

The auditor's recurring responsibility is independent assurance: confirming that controls (approvals, segregation of duties, testing, sign-offs, change control) are present and operating. The auditor may advise on control design when consulted early — early involvement is cheaper than fixing weaknesses after go-live — but must not design, build, operate, or own any control. Doing so would impair independence and disqualify the auditor from later objectively auditing that same control. This independence boundary is one of Domain 3's most frequently tested concepts.

Benefits Realization and the Post-Implementation Review

Value is not assumed at go-live; it is confirmed afterward. Benefits realization is the discipline of tracking whether the promised business outcomes — cost savings, faster cycle times, higher accuracy, regulatory compliance — actually materialized once the system is in steady-state use. The vehicle for this is the post-implementation review (PIR), conducted some weeks or months after deployment when normal operations have stabilized, not on day one.

The PIR compares actual results to the business case, evaluates whether the project met its scope, schedule, and budget, assesses whether controls are operating as designed, and records lessons learned to improve future projects. From an assurance standpoint, the PIR is also where the auditor confirms that any control deficiencies identified during development were remediated before or shortly after go-live. A project that skips the PIR loses its only structured opportunity to prove — or disprove — that the investment was worthwhile, which is why CISA frames the PIR as the closing control of the life cycle.

The auditor reviews the PIR for objectivity: it should be performed by parties who can assess results candidly, ideally with input from someone independent of the build team.