CISM Information Security Risk Management: 124 practice questions

12 of the 124 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. Quantitative risk assessment using ALE calculations: Which risk assessment approach is MOST appropriate in thi

1. A vendor risk assessment using the Common Vulnerability Scoring System (CVSS), because it provides standardized risk scores for technical systems.

   Incorrect. CVSS is a vulnerability severity scoring system for technical vulnerabilities, not a business risk assessment methodology. It does not account for asset value, business impact, or organizational risk context. CVSS scores inform technical remediation prioritization, not business risk investment decisions.
2. Quantitative risk assessment using ALE calculations, because the available data and investment scale support financially precise risk metrics. ✓

   Correct. When historical incident data, asset values, and business impact models are available, quantitative risk assessment using metrics like Annual Loss Expectancy (ALE = ARO × SLE) provides financially precise risk metrics that directly support investment decisions. For a $2M security investment, executives and board members will expect financial justification (e.g., 'the control reduces annual expected loss by $800K'), which quantitative methods provide. The available data specifically enables this approach.
3. A hybrid approach that uses qualitative methods first, followed by quantitative validation of the top three risks.

   Incorrect. While hybrid approaches have merit in some contexts, this scenario has sufficient data to proceed directly with quantitative assessment. A hybrid approach would add process steps and potentially dilute the precision of the quantitative results. Given the investment scale and available data, leading with full quantitative assessment is more appropriate.
4. Qualitative risk assessment using a 5x5 risk matrix, because it is faster and provides sufficient information for decision-making.

   Incorrect. While qualitative assessment is valuable for rapid triage, the scenario provides conditions that enable and require quantitative analysis: historical incident data, documented asset values, and a significant investment decision. Qualitative assessment would not provide the financial precision needed to justify a $2M investment to executive leadership.

When historical data, asset values, and business impact models are available and a significant investment decision is at stake, quantitative risk assessment using ALE calculations is most appropriate.

2. Implement compensating controls to reduce the ALE below: What is the MOST appropriate risk treatment recommend

1. Transfer the risk by purchasing cyber insurance sized to cover the potential $350K annual loss until the modernized replacement system is fully deployed.

   Incorrect. Risk transfer through insurance is a valid treatment option, but it does not reduce the likelihood or impact of the actual security incident—it only provides financial compensation after a loss occurs. For a payment processing system with active encryption vulnerabilities, cyber insurance alone does not address the underlying risk and may not be the most cost-effective option for an 18-month period. Additionally, insurers may require compensating controls before providing coverage for known vulnerabilities.
2. Accept the risk outright because the application will be retired in 18 months and the $500K remediation cost exceeds the annual risk tolerance threshold.

   Incorrect. Risk acceptance is only appropriate when the risk falls within the organization's risk appetite. The current ALE of $350K exceeds the maximum tolerated annual loss of $200K, meaning the risk exceeds the defined risk tolerance and cannot simply be accepted without additional controls to reduce it to an acceptable level.
3. Implement compensating controls to reduce the ALE below $200K for the 18-month interim period, with formal risk acceptance for any remaining residual risk. ✓

   Correct. This approach recognizes that: (1) full remediation is cost-inefficient for a system with an 18-month lifespan, (2) the current risk exceeds the defined tolerance and cannot be simply accepted, (3) compensating controls (e.g., network segmentation, enhanced monitoring, access restrictions) can reduce the ALE to within tolerance at a fraction of the $500K remediation cost, and (4) any residual risk above tolerance requires formal risk acceptance with management accountability. This balances cost efficiency with governance requirements.
4. Mitigate the risk by immediately investing the full $500K to rebuild the encryption capabilities of the legacy payment application well before its scheduled replacement.

   Incorrect. While remediation would address the risk, investing $500K in a system scheduled for replacement in 18 months is difficult to justify. The $500K investment in a legacy system that will be decommissioned is not cost-effective when compensating controls may reduce the ALE below the $200K tolerance threshold at lower cost.

When risk exceeds tolerance and full remediation is cost-inefficient due to a planned replacement, compensating controls that bring risk within tolerance are the appropriate interim treatment.

3. Risk appetite is the amount of risk the organization is: How should the CISM respond?

1. Risk appetite is the maximum loss the organization could ever survive, while risk tolerance is simply its preferred day-to-day risk level; on that basis the board should receive a comprehensive, detailed line-item list of every current information security risk being actively tracked and monitored across the enterprise.

   Incorrect. This inverts the definitions. Risk appetite is not the maximum survivable loss (that is risk capacity), and a detailed list of all security risks is operational-level reporting inappropriate for board-level governance. Boards need strategic risk metrics, not operational detail.
2. Risk appetite is set independently by the security team, whereas risk tolerance is set by the board of directors; accordingly the board should receive detailed risk tolerance threshold values defined separately for each individual information security domain and control area.

   Incorrect. Both risk appetite and risk tolerance are governance decisions that should be set by the board and senior leadership, not the security team alone. The security team informs and recommends, but the ultimate approval and ownership of risk appetite and tolerance rests with executive leadership and the board.
3. Risk appetite and risk tolerance are effectively synonymous governance terms used interchangeably, so to avoid confusion the CISM should simply report a single consolidated organization-wide residual risk score that summarizes the overall security posture for the board.

   Incorrect. Risk appetite and risk tolerance are distinct concepts and should not be conflated. Using them interchangeably at the board level indicates a governance maturity issue and would provide inaccurate information to the board.
4. Risk appetite is the amount of risk the organization is willing to accept in pursuit of its objectives, while risk tolerance is the acceptable variation around that appetite; the board should receive risk appetite metrics showing whether the risk profile remains within the defined appetite. ✓

   Correct. Risk appetite is the broad statement of the amount and type of risk an organization is willing to pursue or retain in pursuit of its strategic objectives. Risk tolerance represents the specific acceptable variance around the risk appetite—the bounds within which the organization will operate. At the board level, reporting should focus on whether the organization's risk profile is within the defined appetite, with breaches of tolerance flagged for board attention and decision.

Risk appetite is the desired risk level; risk tolerance is the acceptable variation around that appetite. Boards receive risk appetite compliance metrics, not operational risk details.

4. RTO of 4 hours based on the contract penalty threshold: What RTO should the CISM recommend, and what BCP requi

1. RTO of 4 hours based on the contract penalty threshold, which reveals a gap because current technical recovery capability of six hours cannot meet the business RTO; the BCP requirement is to invest in faster recovery or formally accept and document the penalty risk. ✓

   Correct. The BIA process first identifies business-driven recovery time requirements (RTO) based on impact thresholds, then compares these to current technical capabilities. The $200K contract penalty threshold at 4 hours establishes the maximum tolerable downtime (MTD), setting the business-required RTO at less than 4 hours. The current 6-hour technical recovery creates a gap. The BCP must either: invest in faster recovery capabilities (hot standby, automated failover) to meet the business RTO, or formally document and accept the risk that the 4-hour threshold may be breached, with documented approval from appropriate management. This gap analysis is the core output of BIA feeding into BCP/DRP development.
2. RTO of 8 hours, because the manual workaround sustaining 20% of volume prevents total revenue loss, allowing the remaining technical recovery to be completed later during normal business hours without triggering the contract penalty clause.

   Incorrect. The manual workaround's 20% capacity does not eliminate the business impact—it only mitigates 20% of revenue loss while the remaining 80% is still lost, and the contract penalty at 4 hours is independent of manual workaround capacity. RTOs must be based on business impact thresholds, not on the availability of degraded-mode operations.
3. RTO of 4 hours because it matches the contract penalty threshold, and recovery must therefore begin the instant an outage is detected so that restoration completes inside the existing six-hour technical recovery window the incident response team currently operates under during outages.

   Incorrect. If technical recovery requires 6 hours, setting the RTO at 4 hours is aspirational but unachievable with current technical capabilities. An RTO must be both business-driven AND technically achievable. Setting an unachievable RTO creates false assurance in the BCP.
4. RTO of 6 hours because that reflects the actual technical recovery time, and no additional BCP requirement is needed since the system can be brought back within a window the organization considers acceptable for its retail order operations.

   Incorrect. An RTO of 6 hours would exceed the 4-hour contract penalty threshold, triggering $200K in penalties. The RTO must account for business impact thresholds, not just technical recovery capability. Setting RTO equal to technical recovery time ignores the business requirement.

BIA establishes business-driven RTOs based on impact thresholds. When technical recovery time exceeds the business-required RTO, the BCP must address this gap through investment or formal risk acceptance.

5. Collaborate with the CRO to ensure information security: What is the BEST approach for the CISM to take?

1. Request that the board establish a separate information security risk committee that reports independently of the ERM structure, so that security concerns retain dedicated visibility and are not diluted among financial and operational risks.

   Incorrect. Creating separate reporting structures fragments risk governance and undermines the consolidation effort led by the CRO. While a security-focused subcommittee may be appropriate, it should operate within the ERM structure, not independently of it. Independent reporting would likely reduce the CISM's influence and resource access rather than increase it.
2. Collaborate with the CRO to ensure information security risk criteria, categories, and escalation thresholds are incorporated into the ERM framework, and that security risks are consistently translated into business impact terms. ✓

   Correct. ERM integration is beneficial for information security because it ensures security risks compete for executive attention alongside other enterprise risks. The CISM's role is to ensure that security risk categories, criteria, and escalation thresholds are appropriately defined within the ERM framework and that security risks are expressed in business impact language (financial, operational, reputational) rather than technical terms. This approach elevates security risk visibility while maintaining enterprise governance coherence.
3. Accept the ERM framework exactly as designed by the CRO and report all security risks using the standard enterprise risk categories, even where those categories fail to capture the full technical nuance of information security exposures.

   Incorrect. Simply accepting the ERM framework without ensuring that information security risk characteristics are properly represented may result in security risks being miscategorized or undervalued. The CISM has an obligation to advocate for appropriate representation of security risks within the framework, not to passively accept a potentially inadequate structure.
4. Maintain a completely separate information security risk register and report it independently to the board, effectively bypassing the ERM framework so that security risk retains its own distinct governance pathway.

   Incorrect. Maintaining a parallel risk reporting structure undermines the ERM framework and creates confusion at the board level. It also positions security risk as siloed from enterprise risk, reducing the CISM's influence and making it harder to get security investments approved in the context of overall enterprise risk.

The CISM should collaborate with the CRO to ensure security risk criteria are properly incorporated into the ERM framework, with security risks expressed in business impact terms.

6. Conduct a threat modeling exercise using STRIDE: Which risk identification approach would provide the MOST com

1. Conduct a penetration test of the mobile application, as this provides real-world evidence of exploitable vulnerabilities.

   Incorrect. While penetration testing is a valuable validation activity, it is focused on finding exploitable technical vulnerabilities rather than comprehensively identifying all risks. Penetration tests are typically conducted within defined scope and time constraints and may not identify business logic risks, regulatory risks, or operational risks. For pre-production risk identification, threat modeling is more systematic and comprehensive.
2. Conduct a threat modeling exercise using STRIDE or a similar methodology to systematically identify threats across all application components and data flows. ✓

   Correct. Threat modeling is specifically designed for pre-production risk identification of complex systems. Using STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) systematically examines each component and data flow against each threat category. For a mobile banking application, this would identify threats across: mobile client security, API security, server-side processing, data storage, third-party integrations, and regulatory compliance risks. Threat modeling supplements technical testing with structured risk identification.
3. Review security incidents at peer financial institutions that involved mobile banking applications to identify relevant risks.

   Incorrect. Reviewing peer incidents provides useful threat intelligence but is a reactive, backward-looking approach that identifies risks others have already experienced. It does not provide a systematic, comprehensive view of the specific risks in this application's architecture. This is a useful supplement but not the primary risk identification methodology.
4. Review the development team's existing security test results, as they have already conducted comprehensive testing and no critical vulnerabilities were found.

   Incorrect. Development team security testing typically focuses on known vulnerability patterns and code-level security. It may not assess business logic risks, third-party integration risks, regulatory risks, user behavior risks, or supply chain risks. Relying solely on development testing for a production risk assessment is insufficient.

Threat modeling using STRIDE or similar methodologies provides the most systematic and comprehensive pre-production risk identification by examining threats across all components and data flows.

7. The risk register may no longer accurately reflect: What is the PRIMARY concern with this situation?

1. The accepted risks that lack defined review dates cannot be reported to the board and must all be formally re-assessed before the next scheduled board meeting takes place.

   Incorrect. Board reporting timing does not drive the urgency of this concern. The primary issue is the operational risk of acting on outdated risk information, which affects decisions continuously—not just at board reporting time.
2. The risk register has simply grown too large and should be trimmed down to only the organization's top ten risks in order to keep management focused and administratively simple.

   Incorrect. Reducing the register to 10 items does not address the staleness problem and may result in critical risks being removed from active tracking. The appropriate solution is a governance process to ensure timely updates, not arbitrary reduction.
3. The risk register may no longer accurately reflect the current risk landscape, leading the organization to make resource allocation decisions based on outdated and stale risk information. ✓

   Correct. A risk register's value depends entirely on its accuracy and currency. Stale risk entries—especially 'risk accepted' entries without review dates—may reflect risks that have materially changed: the threat may have escalated, the control environment may have changed, the asset value may have increased, or the regulatory landscape may have shifted. Decisions about security investment, resource allocation, and risk treatment based on a stale register may misalign resources against outdated risk profiles.
4. The individual risk owners have violated the information security policy by failing to update their assigned register entries on the schedule that the governance policy requires of them each period.

   Incorrect. While policy compliance is relevant, focusing on the policy violation misses the substantive risk management concern. The real issue is that the organization may be making security decisions based on outdated risk information, not that policy was violated.

Stale risk register entries, especially accepted risks without review dates, mean security decisions are based on an inaccurate current risk picture, misaligning resources and responses.

8. The lack of behavioral baselines for the vendor's software: What is the MOST critical control gap?

1. The vendor's standing privileged access to 60% of production servers, which creates an unacceptably large blast radius and therefore an enormous scope of potential damage if that trusted software is ever compromised.

   Incorrect. While the broad privileged access creates a large blast radius (scope of potential damage), this is a risk magnitude issue, not the detection gap. The question asks about the detection and response capability gap. Even if privileged access were reduced, without behavioral baselines the attack would still go undetected.
2. The automatic deployment of vendor updates without any prior testing, which allows a maliciously altered update to reach production systems directly without first passing through any security review or validation step.

   Incorrect. While automatic updates without testing is a significant risk (directly enabling the SolarWinds attack pattern), it is a prevention gap, not the most critical detection gap. The question specifically asks about detection and response capability. Even with tested manual updates, a sophisticated supply chain attack can introduce malicious code that passes standard pre-deployment testing.
3. The absence of vendor source code access or binary verification, which prevents the security team from reviewing the vendor's code for deliberately hidden backdoors before that software is trusted and deployed into the production environment.

   Incorrect. Source code access is impractical for most commercial software relationships and would not be an effective primary control even if available—reviewing millions of lines of code for subtle backdoors is beyond most organizations' capability. The more actionable gaps relate to runtime behavior monitoring and update controls.
4. The lack of behavioral baselines for the vendor's software means that malicious activity executed through the compromised vendor software cannot be reliably distinguished from that software's normal, expected behavior on the network. ✓

   Correct. Supply chain attacks like SolarWinds succeed because they operate through trusted, legitimate software with pre-established privileged access. The most critical detection gap is the inability to distinguish malicious behavior from normal vendor software activity. Without behavioral baselines, even with SIEM and EDR deployed, alerts for vendor software activity are suppressed as 'expected' because the security team has no reference for what abnormal looks like. Behavioral baselines enable anomaly detection for privileged software, which is the primary detection mechanism for supply chain compromises.

Without behavioral baselines for privileged vendor software, malicious activity executed through supply chain compromise cannot be distinguished from normal software behavior, making detection impossible.

9. Implement additional controls to reduce the residual risk: What action is MOST appropriate?

1. Implement additional controls to reduce the residual risk down to the Low tolerance level, or otherwise obtain formal documented management risk acceptance if the residual risk genuinely cannot be reduced to Low. ✓

   Correct. When residual risk exceeds the defined risk tolerance, the risk treatment process requires either: (1) implementing additional controls to further reduce the residual risk to within tolerance, or (2) formally escalating for management risk acceptance with full awareness of the gap between residual risk and tolerance. The second option requires explicit management sign-off—not implicit acceptance by inaction. Additional controls for a web application at Medium residual risk might include: penetration testing to identify remaining vulnerabilities, API security controls, enhanced logging and anomaly detection, or network segmentation.
2. Escalate the web application's defined risk tolerance from Low up to Medium so that the stated tolerance is brought into alignment with the residual risk level the current set of controls can realistically achieve.

   Incorrect. Adjusting the risk tolerance upward to match what is achievable inverts the risk management process. Risk tolerance reflects the organization's acceptable risk level for business reasons; it should not be adjusted to justify insufficient control implementation. This approach hides risk rather than managing it.
3. Remove the web application from production entirely until its residual risk has been reduced to Low, on the grounds that the current Medium residual risk exceeds the defined risk tolerance.

   Incorrect. Removing a production system for exceeding risk tolerance is a disproportionate response that ignores the risk avoidance versus risk treatment trade-off. The business value of the application must be weighed against the risk. Risk treatment (additional controls) or formal risk acceptance is a more proportionate response.
4. Accept the Medium residual risk as it currently stands, reasoning that the applied controls have already lowered the exposure substantially from an inherent Critical level down to a far more manageable Medium level.

   Incorrect. Risk acceptance requires the residual risk to be within the defined risk tolerance. The organization's risk tolerance for external-facing applications is Low, and the residual risk is Medium. Accepting a risk that exceeds defined tolerance requires explicit management override, not routine acceptance.

When residual risk exceeds risk tolerance, additional controls must be implemented to reach tolerance, or management must formally accept the gap—tolerance cannot be raised to justify insufficient controls.

10. Present the vulnerability in terms of specific business: How should the CISM frame this communication?

1. Forward the raw technical vulnerability scan report straight to the CFO along with a brief note recommending that the IT team be directed to patch the affected ERP system as soon as a suitable maintenance window can be arranged, scheduled, and approved by the operations team and the affected business owners.

   Incorrect. Routing a technical vulnerability report to a CFO who cannot interpret it bypasses the translation that makes risk communication effective. The CFO cannot act on a technical report, and escalating without context shifts the burden of interpretation to someone without the necessary background.
2. Present the vulnerability in terms of specific business impact, explaining that unauthorized access to financial data could enable fraudulent transactions, regulatory violations such as SOX, and reputational damage, alongside an estimated financial exposure and the projected cost of remediation. ✓

   Correct. CFOs understand financial risk, not technical vulnerability scores. The communication should: (1) Describe what could happen in business terms (fraudulent transactions, unauthorized financial data access, regulatory violation), (2) Quantify the financial exposure (potential fine, fraud loss, incident response cost), (3) Compare remediation cost to risk reduction value (patching may cost $X in downtime and testing vs. $Y in potential exposure), (4) Request a specific decision (approve patching window, accept residual risk, increase monitoring). This framing enables the CFO to make an informed business decision.
3. Escalate the finding through the CIO instead of communicating with the CFO directly, on the principle that technical risk information should always flow upward first through the established technology management chain of command before it reaches other executives.

   Incorrect. For a vulnerability affecting financial systems, the CFO may need to make decisions about acceptable risk, remediation timing, and resource allocation—making direct communication appropriate. The CISM should brief the CIO as well, but routing all communication through the CIO may delay action and reduce the CFO's visibility into financial system risk.
4. Explain that the vulnerability's CVSS score of 9.1 places it firmly in the critical severity category, which under the organization's vulnerability management policy mandates immediate patching within the defined remediation SLA window established for critical ERP system findings.

   Incorrect. A CFO does not know what CVSS means or why a numeric score should compel action. Policy SLAs are internal operational metrics, not executive decision drivers. This framing requires the CFO to translate technical terminology into a business decision, which they cannot do without security expertise.

Risk communication to non-technical executives requires translating technical findings into business impact language: potential losses, regulatory consequences, and remediation cost vs. risk reduction value.

11. The principle that risk management should be integrated: Which ISO 31000 principle would MOST directly address

1. The principle that risk management should be founded on the best available and most current information sources.

   Incorrect. While using current threat intelligence and accurate data is important for risk assessment quality, the 'best available information' principle does not address the integration problem—a program using excellent data but only once per year is still disconnected from ongoing decisions.
2. The principle that risk management should remain transparent and inclusive toward all affected stakeholders.

   Incorrect. The transparency and inclusivity principle addresses stakeholder communication and involvement in risk management processes. While valuable, it does not directly address the problem of periodic disconnected assessments vs. integrated continuous risk management.
3. The principle that risk management should be integrated into all organizational activities and decision-making. ✓

   Correct. ISO 31000's integration principle states that risk management should not be a standalone activity but should be embedded into organizational functions, processes, and decision-making. For a security program, this means risk assessment should be embedded in strategic planning cycles, project initiation, change management, and vendor onboarding—not conducted as a periodic disconnected event. This directly addresses the limitation of annual point-in-time assessments disconnected from business decisions.
4. The principle that risk management should be dynamic and continually responsive to changes in the risk environment.

   Incorrect. The dynamic principle addresses the need to update risk assessments as the risk environment changes—related to the scenario but not the most direct. The integration principle more specifically addresses the problem of disconnection from organizational decision-making processes.

ISO 31000's integration principle requires risk management to be embedded in organizational decision-making rather than conducted as a standalone periodic activity.

12. Implement automated collection of Key Risk Indicators: The CRO asks: 'What is the MOST important operational c

1. Purchase a Governance, Risk, and Compliance (GRC) platform that centralizes all risk data in one repository and automates the production of scheduled risk and compliance reports.

   Incorrect. A GRC platform is a tool for organizing and reporting risk data, not the operational change that enables continuous monitoring. A GRC platform populated with manually updated, periodic data does not provide continuous monitoring capability. The operational change is automated KRI data collection feeding the risk picture continuously.
2. Implement automated collection of Key Risk Indicators from security tools (vulnerability scanners, SIEM, patch management) that continuously feed the risk register with current control status. ✓

   Correct. Continuous risk monitoring requires replacing periodic manual assessment with automated KRI collection that reflects current control effectiveness and threat exposure. When vulnerability scan results, patch compliance status, security monitoring coverage, and configuration compliance automatically update the risk picture, risk managers can see risk changes in real time rather than waiting for the next scheduled assessment. This is the operational foundation of continuous monitoring.
3. Increase the frequency of enterprise risk assessments from annual to quarterly, running the same assessment process four times each year.

   Incorrect. Quarterly repetition of the annual assessment process is a frequency increase, not a shift to continuous monitoring. Continuous monitoring requires automated data collection and real-time or near-real-time risk indicators, not periodic manual assessment repetition.
4. Train the business risk owners to update their own risk register entries whenever they notice a change in their area, relying on these manual updates.

   Incorrect. Manual risk owner updates are better than nothing but create inconsistent, incomplete, and delayed risk updates. Business unit risk owners are not monitoring their risks continuously—they have primary job responsibilities. Automation provides more complete and timely data than voluntary manual updates.

Continuous risk monitoring requires automated KRI collection from security tools that continuously reflects current control status and threat exposure, replacing periodic manual assessment snapshots.

Other CISM domains

• Information Security Governance — 131 questions →
• Information Security Program — 124 questions →
• Incident Management — 118 questions →
• All 497 CISM questions →