CISA Practice Question: Information Systems Acquisition, Development, and Implementation
An IS auditor is assessing the controls in an agile development environment. What is the MOST effective way to verify that security testing is performed iteratively?
⚠ Common exam trap
Watch out — candidates often confuse 'planning for security' (e.g., standups or product owner interviews) with 'evidence of security execution' (the DoD), or they mistakenly think a final report proves iterative testing when it only shows a single snapshot.
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
✓
Reviewing the project's definition of done for each sprint
In agile development, security testing must be integrated into each sprint to ensure continuous validation. The 'definition of done' (DoD) is the team's checklist for completing a user story; if it explicitly includes security testing tasks (e.g., static analysis, dynamic scans, or penetration tests), then verifying the DoD proves that security testing was performed iteratively. Option D directly examines this artifact, providing objective evidence of iterative security testing.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Observing a daily standup meeting
Why it's wrong here
A daily standup reveals coordination and progress, not evidence that security testing occurred each iteration. It is tempting because standups are visible agile ceremonies, but they produce no test artefacts. The correct approach examines sprint-level security test results and backlog items, which directly evidence iterative testing.
- ✗
Interviewing the product owner about security priorities
Why it's wrong here
Interviewing the product owner yields opinions about priorities, not objective evidence that security testing ran iteratively. It is tempting because the product owner owns backlog prioritisation, but verbal accounts are not verifiable artefacts. The correct approach examines sprint-level test results and backlog items evidencing iterative execution.
- ✗
Examining the final security test report after release
Why it's wrong here
A final report shows only end-state results, not iterative security testing across sprints. It is tempting because release reports are tangible audit evidence, but they cannot demonstrate per-iteration testing. The correct approach examines sprint-level artefacts, such as backlog items and test logs, to verify iterative execution.
- ✓
Reviewing the project's definition of done for each sprint
Why this is correct
The definition of done is agreed per sprint and should explicitly include security testing criteria. Auditing each sprint's definition of done confirms whether security activities are embedded iteratively, providing direct evidence rather than relying on retrospective claims or final-phase testing.
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 by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.