CISM Information Security Risk Management: 320 practice questions

12 of the 320 Information Security Risk Management questions in the Certsqill CISM bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for CISM? Take the free 5-min readiness check →

1. Map the intelligence to assets and reassess relevant: Which action is most appropriate?

1. Map the intelligence to assets and reassess relevant exposure. ✓

   This tests whether the reported threat applies to the retailer and supplies context for a defensible treatment decision.
2. Raise all payment-service vulnerabilities to critical severity.

   Threat reporting does not prove every vulnerability is exploitable or equally consequential in this retailer’s environment.
3. Subscribe to every available intelligence feed.

   More feeds do not establish relevance to the retailer’s assets, exposure, likelihood, or treatment decision.
4. Issue an incident alert to all store employees.

   Broad awareness may be useful later, but it does not first determine whether the intelligence changes enterprise risk.

Threat intelligence becomes useful when mapped to relevant assets and exposure, supporting a specific treatment decision rather than increasing information volume.

2. Perform a scoped assessment before the service owner: What should security recommend?

1. Block the service until every conceivable risk is eliminated.

   The policy requires assessment before acceptance, not elimination of all risk, and risk treatment can address documented residual exposure.
2. Perform a scoped assessment before the service owner decides acceptance. ✓

   The assessment satisfies the policy prerequisite and gives the authorized owner evidence about exposure, consequences, assumptions, and uncertainty.
3. Use the prior tracking system’s assessment without modification.

   A new service changes systems, dependencies, and context, so inherited assumptions cannot substitute for current scoped analysis.
4. Approve launch and assess risk during the first operating month.

   This bypasses the stated prerequisite and leaves the authorized risk decision unsupported when the service becomes operational.

Because policy requires assessment before authorized acceptance, complete a scoped evaluation before launch rather than letting schedule pressure override governance.

3. Document and escalate the concentration risk: What is the best security action?

1. Wait for an outage before documenting the dependency risk.

   An outage is not required to recognize concentration exposure or satisfy the policy’s review trigger.
2. Direct procurement to source a substitute immediately.

   Sourcing alternatives may be appropriate treatment, but the triggered risk must first be documented and governed.
3. Document and escalate the concentration risk. ✓

   This promptly records the exposure and initiates the policy-required committee review, where treatment options and residual risk can be considered.
4. Add supplier availability and outage trends to the operations dashboard.

   Availability monitoring does not address concentration, consequences, ownership, treatment, or the required committee decision.

The single-provider dependency triggers committee review now; an outage is unnecessary to recognize and govern the exposure.

4. Require a scoped assessment of data: What should security require before approval?

1. Ban all experimentation with generative-AI services.

   The policy restricts unassessed use of confidential client data; it does not prohibit every experiment or every data-free evaluation.
2. Approve using the vendor’s general security documentation plus internal access controls.

   Vendor material can inform the assessment but cannot establish this partnership’s specific data exposure, consequences, dependencies, or residual risk.
3. Require a scoped assessment of data, threats, weaknesses, impacts, and uncertainty. ✓

   A scoped assessment satisfies the policy prerequisite and determines whether the pilot’s controls and residual exposure support approval.
4. Permit a time-limited pilot with access controls and retrospective review.

   Access controls and limited duration may reduce exposure, but retrospective review violates the stated prerequisite for confidential-data use.

The data policy makes assessment a prerequisite; evaluate the pilot’s specific exposure before deciding whether controls support approval.

5. Validate the relevant weakness and assess affected: What should security do?

1. Dismiss the intelligence because the architecture differs.

   Architectural differences create uncertainty requiring validation, not dismissal of potentially relevant threat information.
2. Treat the retailer as compromised because the group is capable.

   Threat capability alone does not establish occurrence, vulnerability, exposure, or consequence in the retailer’s environment.
3. Apply the same treatment selected by the targeted retailers.

   Other retailers’ treatments may inform analysis, but cannot substitute for assessing this organization’s architecture, exposure, and consequences.
4. Validate the relevant weakness and assess affected business exposure. ✓

   This separates threat capability from vulnerability and consequence, producing evidence for a proportionate treatment recommendation.

Validate whether the relevant weakness exists, then assess business exposure; threat capability alone cannot establish the retailer’s risk.

6. Reassess the dependency and document changed exposure: What should security do first?

1. Reassess the dependency and document changed exposure before treatment. ✓

   Reassessment connects the external event to the company’s affected shipments, exposure, uncertainty, and possible responses before a treatment decision.
2. Mark the dependency high risk without documenting scope or uncertainty.

   The event warrants review, but a rating alone does not establish affected services, consequences, uncertainty, or suitable treatment.
3. Replace the carrier immediately without assessing feasibility or impact.

   Replacement may be a treatment, but acting immediately without assessing scope, feasibility, consequences, and alternatives may create additional operational risk.
4. Wait for the carrier to confirm customer impact.

   The ransomware event already provides relevant evidence that the dependency context may have changed; waiting can delay reassessment.

A material external event changes dependency context, so reassess the affected exposure before selecting treatment.

7. Update the replacement’s scope and assumptions: What should the security manager do?

1. Keep the historical rating until the next annual review.

   Materially changed systems and dependencies make the historical assessment stale; an annual schedule does not override a reassessment trigger.
2. Delete the retired application and leave the replacement unrated pending review.

   Removing obsolete information without assessing the replacement creates an undocumented current exposure and weakens risk visibility.
3. Update the replacement’s scope and assumptions, then reassess its exposure. ✓

   This replaces obsolete assumptions with current asset, dependency, threat, vulnerability, consequence, and uncertainty information.
4. Transfer the old rating directly to the replacement system.

   Different dependencies and operating context mean the old rating may not represent the replacement’s current likelihood, impact, or weaknesses.

The replacement changed scope and dependencies, so update assumptions and reassess rather than preserve or copy the obsolete rating.

8. Assess the proposed service scenarios and uncertainty: Which action is best?

1. Assess the proposed service scenarios and uncertainty. ✓

   Early scenario analysis gives leadership decision-relevant exposure information while clearly identifying assumptions and unresolved uncertainty.
2. Approve funding based on projected revenue and strategic value.

   Commercial value supports business justification but does not reveal threats, weaknesses, consequences, dependencies, or uncertainty affecting approval.
3. Adopt another firm’s workspace assessment as the partnership’s recommendation.

   External experience may inform assumptions, but cannot represent this partnership’s clients, design choices, dependencies, consequences, or uncertainty.
4. Wait until the final architecture exists before beginning risk analysis.

   Early analysis can expose material assumptions and influence design; waiting discards useful information before the funding decision.

Before funding, analyze plausible service scenarios and uncertainty so leadership can judge exposure and design dependencies.

9. A documented assessment linking the attack method: Which evidence most directly establishes that result?

1. A briefing describing how the retailer’s security team could improve detection of the reported attack method.

   Detection improvements may be useful treatment planning, but do not themselves establish whether the threat changes business risk.
2. A documented assessment linking the attack method to the retailer’s payment assets and potential business impact. ✓

   This connects relevant threat information with assets, exposure, likelihood, and business consequences rather than merely describing threat activity.
3. The intelligence team’s monthly report listing recent payment-platform attack methods and affected industries.

   The report demonstrates information gathering, but does not establish relevance to this retailer’s assets or business exposure.
4. A dashboard showing the number of payment-platform threat indicators received during the reporting period.

   Indicator volume may show monitoring activity, but cannot demonstrate changed exposure, impact, or applicability to the retailer.

The assessment must connect the threat to relevant assets and business consequences; intelligence volume or response proposals are indirect evidence.

10. Document a risk assessment of the new service: Which evidence most directly establishes that result?

1. Run an internet-facing scan and record its technical findings.

   A scan identifies technical weaknesses, but does not establish business impact, relevant threats, assumptions, or overall exposure.
2. Obtain the owner’s business-criticality classification and approval.

   Criticality supplies useful business context, but alone does not assess threats, vulnerabilities, flows, or resulting exposure.
3. Review the launch checklist for completed safeguards.

   A checklist shows project activity and safeguard completion, but does not determine the service’s changed exposure.
4. Document a risk assessment of the new service. ✓

   A documented assessment is the appropriate evidence when it covers the stated flows, threats, vulnerabilities, impacts, assumptions, and exposure.

A documented risk assessment establishes changed exposure when it covers the service’s context, threats, weaknesses, impacts, and assumptions.

11. An assessment of supplier dependency: Which evidence is most direct?

1. Qualify additional suppliers through procurement governance.

   Supplier qualification may reduce concentration later, but the activity does not itself establish the current risk or its magnitude.
2. Review the supplier’s clean vulnerability and remediation reports.

   Those reports address known supplier weaknesses but omit concentration, replacement constraints, plausible threats, and patient-service consequences.
3. Exercise manual scheduling procedures for a short outage.

   The exercise can test a limited continuity response, but it does not establish the broader concentration exposure or nine-month substitutability constraint.
4. An assessment of supplier dependency, replacement constraints, threats, and patient-service consequences. ✓

   This assessment covers the supplier dependency, limited substitution, plausible disruptions, and patient-service consequences required by the stem.

Connect dependency and replacement constraints with plausible threats and their effects on patient services.

12. A completed risk assessment covering the tool’s: What evidence most directly demonstrates that the technology

1. A pilot demonstration using synthetic client records.

   Synthetic testing may reduce exposure during experimentation, but does not satisfy the required assessment for client-information processing.
2. A completed risk assessment covering the tool’s client-data use and relevant consequences. ✓

   This demonstrates the policy-triggered assessment considered the technology’s information use and business consequences before processing begins.
3. A vendor security questionnaire completed by the tool provider.

   The questionnaire supplies vendor information, but does not demonstrate the partnership assessed its own use and consequences.
4. A contract clause requiring the provider to notify the partnership about security incidents.

   Notification language supports governance and response, but does not establish that the new technology’s risk was assessed.

Because policy requires assessment before client-data processing, the completed organization-specific assessment is decisive evidence.

Other CISM domains

• Information Security Program — 528 questions →
• Incident Management — 480 questions →
• Information Security Governance — 272 questions →
• All 1600 CISM questions →
• CISM certification: requirements, cost and exam format →