CISA Practice Question: Information Systems Acquisition, Development, and Implementation
An organization is implementing a new CRM system using an iterative development methodology. The IS auditor wants to verify that appropriate controls are in place. Which THREE of the following are essential controls for iterative development? (Select THREE.)
⚠ Common exam trap
CISA often tests whether candidates can match controls to the development methodology; candidates incorrectly apply waterfall controls (upfront sign-off, universal change control boards) to iterative projects, misunderstanding that iterative methods require lightweight, continuous controls.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Risk assessment at the start of each iteration
Option B is correct because iterative development delivers functionality in short cycles, so a risk assessment must be repeated at the start of each iteration to identify new or changing risks (e.g., scope creep, integration issues, security flaws) before that increment is built. Option C is correct because iterative projects produce frequent code and artifact changes across parallel workstreams, making version control and configuration management essential to maintain baselines, traceability, and rollback capability. Option E is correct because iterative methodologies depend on continuous stakeholder involvement, and reviews/feedback after each iteration validate that the evolving product meets business needs and allow course corrections early. Option A is not appropriate because iterative development deliberately avoids freezing a complete requirements document up front; requirements evolve through iterations. Option D is not essential because requiring a change control board for every change would impose a heavyweight, waterfall-style gate that conflicts with the speed and flexibility of iterative delivery, where many changes are handled within the iteration backlog.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Formal sign-off on a complete requirements document before development begins
Why it's wrong here
Iterative development accepts evolving requirements, so demanding a complete requirements document signed off before work starts reinstates a waterfall gate that the methodology deliberately avoids. Such baselines suit fixed-scope waterfall projects; iterative work instead needs controls over each increment, such as review and acceptance of delivered functionality.
- ✓
Risk assessment at the start of each iteration
Why this is correct
Each iteration introduces new or changed functionality, so risks must be reassessed before development begins rather than once at project inception. Performing risk assessment at the start of every iteration ensures newly identified threats are addressed within that cycle, satisfying the iterative methodology's need for continuous control.
- ✓
Version control and configuration management
Why this is correct
Iterative development produces frequent code changes across parallel workstreams, so version control and configuration management are essential to track revisions, prevent conflicting changes and enable rollback. This control directly addresses the integrity and traceability requirements created by repeated iteration cycles.
- ✗
A mandatory change control board for every change
Why it's wrong here
Routing every change through a change control board imposes heavyweight governance unsuited to iterative delivery, where small frequent increments would stall. Change boards suit high-risk, low-frequency changes in stable environments; iterative development instead relies on automated testing, version control and backlog-level approval to manage change.
- ✓
Frequent stakeholder reviews and feedback after each iteration
Why this is correct
Iterative development relies on short cycles delivering incremental functionality, so stakeholder reviews and feedback after each iteration confirm the product meets evolving business requirements and corrects direction early. This satisfies the methodology's need for continuous validation rather than a single end-stage acceptance test.
Go deeper
Related to this question
About these practice questions
This CISA question is part of Courseiva's 934-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official ISACA exam blueprint
This CISA practice question is part of Courseiva's free ISACA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CISA exam.