mediumMultiple Choice
CRISC Practice Question: An internal audit report identifies that the IT…
An internal audit report identifies that the IT department did not patch a critical vulnerability in a database server for 90 days. The risk manager wants to identify the root cause risk. Which approach should be used?
⚠ Common exam trap
Candidates often confuse operational remediation (e.g., rescanning or interviewing) with risk identification analysis, failing to recognize that the question specifically asks for identifying the root cause risk, not just confirming or logging the finding.
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
✓
Perform a root cause analysis on the patching process
The risk manager needs to identify the root cause risk, which requires understanding why the patching process failed to apply a critical security update within the required timeframe. A root cause analysis (RCA) on the patching process systematically examines procedural breakdowns, such as missed scanning cycles, lack of change management approval, or insufficient prioritization of database-specific patches (e.g., Oracle Critical Patch Updates). This approach directly addresses the underlying process deficiency rather than merely documenting or re-verifying the vulnerability.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Interview the database system owner
Why it's wrong here
Interviewing the database system owner yields one person's account of the delay, not the underlying risk cause across process, governance and control. It is tempting because the owner holds operational knowledge, but root cause analysis requires structured techniques such as causal analysis or control assessment.
- ✗
Conduct a new vulnerability scan
Why it's wrong here
A scan only detects current vulnerabilities; it cannot reveal why patching lapsed for 90 days, so the causal risk stays hidden. Scanning is tempting because it validates exposure and would be right for confirming remediation or discovering new weaknesses, not for root-cause analysis of a process failure.
- ✗
Update the risk register with the finding
Why it's wrong here
Recording the finding documents the symptom but does not investigate the underlying process or control failure that allowed 90 days of non-patching. Register updates are tempting because risk tracking demands them, and would be right after root cause is established, not as the diagnostic method itself.
- ✓
Perform a root cause analysis on the patching process
Why this is correct
Root cause analysis traces the 90-day patching failure back to its underlying process breakdown, such as missing ownership or change-approval bottlenecks, rather than treating the symptom. This satisfies the risk manager's need to identify the root cause risk within the patching process itself.
Go deeper
Related to this question
About these practice questions
This CRISC question is part of Courseiva's 1,062-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 CRISC 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 CRISC exam.