CRISC IT Risk Identification Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Reframe each suggestion by asking what adverse event the control is meant to prevent, and record that adverse event as the risk.

  Why this is correct

  This is the correct technique. Controls are responses to risk, so the practitioner must surface the underlying event the control addresses. Asking what could go wrong that multifactor authentication or transaction limits would mitigate yields genuine risks such as account takeover or unauthorized high-value transfers. The controls are then captured separately in treatment planning, where they belong. This keeps the identification phase focused on uncertain events affecting objectives and preserves a clean, estimable register for the retail bank.

• ✗

  Escalate to the CISO because stakeholders who cannot distinguish controls from risks should not participate in risk identification workshops.

  Why it's wrong here

  Excluding business stakeholders would undermine the workshop's purpose. CRISC emphasizes that risk identification draws on business and process knowledge, and stakeholders naturally describe concerns in control language because that is how they manage their operations daily. The practitioner's role is to translate those concerns into event-based risk statements, not to remove the people who understand the payment process. Escalation also addresses a facilitation skill gap with authority rather than with technique, leaving the underlying identification problem unresolved.

• ✗

  Accept the control suggestions as risks but tag them so they are excluded later during risk evaluation and treatment planning.

  Why it's wrong here

  Tagging controls as risks and filtering them afterward corrupts the register before it is even built. Risk identification should capture the uncertain events that could affect objectives, not the mechanisms intended to reduce them. If controls are logged as risks, likelihood and impact estimates become meaningless because a control does not have an inherent probability of occurring and causing loss. Downstream evaluation, aggregation, and reporting would then be built on mislabeled entries that cannot be compared against risk appetite.

• ✗

  Record both the controls and the underlying events in the register, then let the risk committee decide which entries to retain.

  Why it's wrong here

  Deferring the distinction to a committee pushes a definitional problem into governance. The register would contain a mixture of events and responses, so likelihood, impact, and inherent versus residual comparisons become incoherent. Committees should adjudicate risk appetite and prioritization, not repair taxonomy errors that the practitioner is equipped to resolve during facilitation. Recording both also inflates the register and can create false dependencies where a control appears as a separate risk requiring its own treatment, which is circular.

Go deeper

Related to this question