Certified in Risk and Information Systems Control CRISC (CRISC) — Questions 976–1050

Periodic review of KRI thresholds is a key element because KRIs must remain aligned with the evolving risk landscape; thresholds that are not reviewed can become obsolete, leading to false positives or missed risk indicators. Clearly defined roles and responsibilities ensure accountability for control execution, monitoring, and escalation, which is foundational to any effective control monitoring framework.

The CIA triad (Confidentiality, Integrity, Availability) plus Accountability are core security principles. Correct matches: Confidentiality prevents unauthorized disclosure, Integrity ensures accuracy, Availability guarantees access, and Accountability enables traceability.

Credential theft defeats knowledge-based authentication regardless of password strength, so the strongest mitigation changes the authentication factor itself. Phishing-resistant FIDO2 authentication uses origin-bound public-key cryptography, meaning stolen passwords or relayed phishing sessions cannot authenticate. Complexity rules, lockout, and awareness training are useful supporting controls but do not break the theft-to-access path.

The log data shows repeated failed login attempts from multiple IP addresses targeting user accounts, which directly measures authentication failures over time. This makes it the most suitable source for calculating the number of failed authentication attempts per hour, a key risk indicator for brute-force or credential-stuffing attacks.

Leading KRIs detect conditions that precede an adverse event, giving the risk owner time to act. Capacity utilization thresholds and single points of failure both signal latent availability weaknesses before an outage occurs. Outage counts, mean time to restore, and patch currency either describe past events or relate to a different risk category, so they do not satisfy the requirement for early warning indicators specific to cloud service availability.

The correct matches are Risk with 'effect of uncertainty on objectives', Threat with 'circumstance/event that can adversely impact', and Vulnerability with 'weakness that can be exploited'. Common confusions include swapping definitions between these terms.

ALE (Annualized Loss Expectancy) is calculated as ARO × SLE. With an ARO of 0.5 (the event is expected to occur once every two years) and an SLE of $200,000, the ALE is 0.5 × $200,000 = $100,000. This figure represents the expected average annual financial loss from this risk, which is the value used to justify the cost of controls.

Because service credits only refund fees and cannot restore lost orders, the organization retains the operational impact of a vendor outage. A documented and tested business continuity plan with a manual fallback directly reduces that impact by keeping order processing alive, whereas contract changes, assurance reports, and insurance all leave the business unable to operate during the outage.

The organization is actively reducing the likelihood and impact of a vulnerability by deploying a WAF and network segmentation. These compensating controls are classic risk mitigation actions. Risk mitigation is the appropriate strategy when an organization chooses to implement controls to bring residual risk within appetite rather than accepting, transferring, or avoiding the risk entirely.

The report's primary purpose is to enable the audit committee to oversee IT risk effectively. That requires a balanced presentation of exposures and control effectiveness, including unfavorable information such as overdue remediation. Reports skewed toward technical detail, only positive trends, or exhaustive risk lists fail to support informed governance and can hide material exposures from those accountable for oversight.

Mitigation through encryption is the recommended first response because it directly addresses the unencrypted transmission of patient data and aligns with the organization's low risk appetite for confidentiality breaches. Encryption reduces both the likelihood of successful interception and the impact if interception occurs, providing a proportionate and technically feasible control. Acceptance, transfer, and avoidance are either misaligned with appetite or unnecessarily disruptive given the availability of a targeted preventive control.

Before any risk assessment activities can begin, the organization must establish the context—defining the scope, risk appetite, criteria for risk evaluation, and the business objectives the assessment supports. Without this foundational step, subsequent identification of assets, threat analysis, or control implementation would lack alignment with business goals and could produce irrelevant or misleading results. This aligns with the ISACA Risk IT framework and the CRISC domain of IT Risk Assessment.

Risk mitigation controls reduce the likelihood or impact of a risk. Tokenization and TLS encryption both directly reduce the risk of credit card data interception by making the data unusable or unreadable to attackers. Cyber insurance transfers risk, avoiding online payments avoids risk, and outsourcing shares risk; none of these directly mitigate the technical vulnerability.

Residual risk is the level of risk remaining after controls are applied. Since the scenario explicitly states that no control is currently in place, the residual risk remains identical to the inherent risk level, which is 'critical'. Therefore, the residual risk is also critical.

Inherent risk of 25 (5×5 matrix, maximum) dropping to residual risk of 9 after control evaluation demonstrates that the controls materially reduced the risk exposure. A reduction from 25 to 9 is significant, indicating the controls are functioning as intended to mitigate the identified threat. This is the standard interpretation in CRISC risk analysis.

Actionable, comparable, and ERM-aligned reporting requires consistent risk scoring criteria and definitions so risks can be compared across units and over time. It also requires presenting risk in business context, linking technical findings to strategic objectives so the board can prioritize. Raw scan outputs and zero-residual-risk filters fail to provide meaningful governance information, and divergent local scales break comparability.

A SIEM is only as reliable as the events it receives, so the priority is ensuring those events are authentic and consistently time-stamped. Protecting log sources and the transport path against tampering, and synchronizing clocks, prevents attackers from hiding activity or fabricating evidence. Volume, tuning, and packet capture all matter operationally but none of them restores confidence in data that could have been altered.

KRIs that are not directly mapped to any risk in the risk register provide no actionable insight for risk monitoring or decision-making. Removing them reduces noise and ensures the remaining 20 KRIs are all linked to specific risks, which is essential for effective risk-based reporting and resource allocation.

Risk reporting to executives must translate technical findings into business language. Grouping vulnerabilities by affected processes and assets and expressing exposure through impact and likelihood gives leaders the context needed to prioritize remediation spending against organizational objectives. Raw counts, technical artifacts, or alphabetical ordering do not support funding decisions because they omit the business consequences that drive risk-based prioritization.

Vulnerabilities gain risk significance through the assets they affect, so determining the value and criticality of the legacy inventory system establishes the potential business consequence of exploitation. Without this asset context, an unpatched platform is merely a technical finding. Vendor counts, audit cadence, and open finding totals are organizational metrics that do not describe how much loss the manufacturer would suffer from this specific vulnerability.

A top-down risk identification approach starts with the organization's strategic objectives and critical business processes, then identifies IT risks that could affect them. Mapping the POS system to these objectives ensures that risk identification is business-driven and prioritizes risks with the greatest potential impact on the retailer's goals. This approach contrasts with bottom-up methods that begin with assets or vulnerabilities.

A Data Flow Diagram (DFD) review is most effective because it visually maps how payment card data moves through the POS system—from card swipe to authorization to storage—identifying exactly where data is at rest, in transit, or processed. This allows the team to pinpoint specific PCI DSS control gaps (e.g., unencrypted transmission, unnecessary retention) that other techniques might miss.

Non-compliance with PCI DSS is a direct violation of regulatory requirements, making it a compliance risk. For a mobile payment application handling cardholder data, PCI DSS mandates specific security controls (e.g., encryption of PAN, access controls, logging). Failure to meet these standards exposes the startup to fines, legal sanctions, and potential loss of the ability to process payments.

Sampling only tests a subset of the population, so a passing result on 30 logins provides assurance only about those sampled items — it does not prove the control operates effectively across the entire population. This is the fundamental limitation of audit sampling: the conclusion is limited to the sample unless statistical sampling with a defined confidence level is used.

The most relevant threat to a public API that initiates account transfers is abuse of authorization logic, such as broken object level authorization, because it directly enables unauthorized financial transactions. Physical accidents, competitive intelligence, and power outages are generic threats that do not address the specific exposure created by exposing transfer functionality to third parties. Identifying API-specific threats ensures controls such as object-level access checks and strong authentication are designed appropriately.

B is correct because the effectiveness of a control is determined by its ability to reduce risk to an acceptable level, which is directly measured by key control indicators (KCIs) such as the control deficiency rate and test results. These metrics provide empirical evidence of whether the control is operating as intended and mitigating the identified high-risk finding. Without such performance data, any assessment of effectiveness is speculative.

The dashboard shows the control operating effectively for six months, yet a material weakness was found. This discrepancy most likely arises because the Key Risk Indicator (KRI) thresholds were set incorrectly, meaning the monitoring system was calibrated to report acceptable risk levels even when the control was actually failing. Incorrect thresholds cause false positives in the dashboard, masking the true control deficiency.

Risk identification captures uncertain events that could affect objectives, while controls are the responses selected later during risk treatment. When stakeholders offer a control, the practitioner should ask what adverse event it is meant to prevent and record that event as the risk. This preserves the register's integrity, allows likelihood and impact to be estimated meaningfully, and keeps the control where it belongs, in treatment planning, so evaluation and appetite comparison remain coherent.

A centralized risk and control monitoring platform that aggregates data while enforcing common reporting standards directly addresses the root causes: inconsistent KRI definitions, differing timeframes, and no aggregation mechanism. It preserves local autonomy in how regions execute monitoring while giving the corporate risk team and board consistent, timely global visibility. This is the only option that solves both the standardization and aggregation problems simultaneously.

In a typical 5x5 risk heat map, the overall risk rating is determined by the intersection of likelihood and impact values. With likelihood 4 and impact 5, the cell falls in the 'Critical' zone (commonly defined as likelihood 4-5 and impact 4-5). This aligns with the convention where 5=Critical, 4=High, 3=Medium, 2=Low, 1=Informational, making D the correct answer.

The two controls that actually prevent privileged client data from being exposed when a personal device is lost or compromised are escrowed full-device encryption and MDM with remote wipe plus containerization. Together they protect data at rest and allow selective removal of firm data, while the other choices are policy, perimeter, or financial measures that do not stop the leakage scenario.

Purchasing cyber insurance transfers the financial risk of a data breach to the insurer, making it a classic example of risk transfer. In risk management, transfer shifts the impact of a loss to a third party (e.g., an insurance carrier) without eliminating the underlying threat or vulnerability. This aligns with the CRISC domain of Risk Response and Mitigation, where transfer is a distinct response strategy.

The vendor risk appetite policy explicitly requires SOC 2 Type II reports for critical vendors, and the vendor only provided a Type I report. The risk manager must enforce the policy as written, so the correct action is to request the Type II report from the vendor. Accepting a Type I or exempting the vendor would violate the stated policy and undermine the control.

Annualized Loss Expectancy (ALE) is calculated as Loss Event Frequency (LEF) multiplied by Loss Magnitude (LM). Here, LEF = 0.2 per year and LM = $5,000,000, so ALE = 0.2 × $5,000,000 = $1,000,000. This represents the expected annualized financial loss from the ransomware scenario.

External factors that increase inherent risk are those outside the organization's control, such as the evolving threat landscape and new regulations. The sophistication of cybercriminals and government-imposed data privacy regulations are both external. Internal factors like lack of training, outdated encryption, and high turnover are within the organization's control and are considered internal vulnerabilities or weaknesses.

Data residency obligations are satisfied only by evidence of where data actually resides plus a binding commitment that it stays there. Verifying the provisioned regions, including replication and backup locations, and securing contractual data-location terms directly addresses the regulatory requirement. General certifications and availability agreements speak to security or uptime, not geographic confinement of payment data.

The scenario describes management choosing to keep the high-risk payment gateway in production while purchasing an insurance policy to cover financial losses. This is risk transfer because the financial impact of a potential breach is shifted to the insurer. Risk mitigation would require implementing controls to reduce likelihood or impact, avoidance would require eliminating the gateway, and acceptance would mean bearing the loss without transferring it.

The correct matches align each framework with its primary regulatory focus. Common confusions occur between security-focused frameworks like PCI DSS and privacy-focused ones like HIPAA, or between data protection (GDPR) and financial reporting (SOX).

The best response because a 5% bypass rate indicates a control weakness that could lead to financial loss or fraud. From a risk perspective, the root cause of the bypasses must be investigated to understand why the control is being overridden, and compensating controls should be implemented to mitigate the residual risk. Simply accepting or documenting the rate without action ignores the potential for systemic issues or targeted exploitation.

The IT risk universe should be comprehensive — it must capture all potential IT risks regardless of likelihood, including cyber, operational, compliance, third-party, project, and change risks. Defining the universe is an identification exercise, not a prioritization exercise; filtering by likelihood, budget, or past occurrence at this stage would create blind spots and undermine the risk register's completeness.

The risk manager should follow the organization's established risk assessment and reporting criteria. Since the vulnerability has low likelihood and compensating controls keep residual risk within tolerance, it does not meet the threshold for board escalation. Documenting it in the risk register with supporting rationale and reporting through normal channels ensures accurate risk visibility while avoiding unnecessary escalation.

Effective risk reporting must provide actionable information that enables decision-makers to prioritize and respond to risks. Option C is correct because reports should highlight key risk indicators (KRIs), trends, and control effectiveness, not just raw data, so that management can make informed decisions about risk treatment and resource allocation.

A key risk indicator (KRI) for credit risk must directly measure the likelihood or impact of a borrower failing to meet their obligations. The percentage of loans that are in default or non-performing is a direct, quantitative measure of credit risk exposure, as it reflects the actual realization of credit losses. This aligns with the CRISC focus on monitoring risk levels to trigger timely responses.

When SCCs are used as a cross-border transfer control, their adequacy depends on being current with regulatory requirements and being supported by a transfer impact assessment for each destination jurisdiction. The risk practitioner must evaluate legal validity and local law conflicts, not just technical security or retention practices. This ensures the risk response actually mitigates the regulatory risk of unlawful data transfers under GDPR and local laws.

Implementing manual overrides and additional monitoring reduces the probability or impact of the legacy system failure without eliminating the risk entirely. This is the definition of risk mitigation, as it applies controls to lower the residual risk to an acceptable level while the system remains in operation.

Quantitative risk analysis assigns numeric, often monetary, values to risk using models such as ALE (SLE × ARO) or Monte Carlo simulation. Its principal drawback is that it requires substantial historical loss data, asset valuations, and modeling effort, making it resource-intensive and slow to perform compared with qualitative approaches like risk matrices. This data dependency and time cost is the recognized limitation tested here.

The risk register is a living document that should be updated to reflect changes in risk levels after controls are implemented. Updating the ratings provides an accurate view of residual risk, which supports prioritization, resource allocation, and risk-based decision making. While compliance and audit are important, they are not the primary purpose of the update.

Misconfigured cloud storage most often results in data exposure through overly permissive access policies and goes unnoticed due to insufficient logging and monitoring. These two risks directly affect confidentiality and the ability to detect and respond to incidents. Other options are either less directly related to misconfiguration or are not security risks in the same sense.

The HIPAA Security Rule is built on a risk management framework, and its first required implementation specification is an accurate and thorough risk analysis. Before selecting encryption, access controls, or contracts, the organization must identify and evaluate the risks to electronic PHI. That analysis then informs the selection of reasonable and appropriate safeguards for the portal.

The CVSS base score of 9.0 reflects the intrinsic severity of the vulnerability, but the final risk rating must incorporate compensating controls. The strong firewall and two-factor authentication (2FA) significantly reduce the likelihood of exploitation, as the attacker would need to bypass both network-level filtering and an additional authentication factor. In CRISC methodology, risk is a function of likelihood and impact; here, the controls lower the likelihood, resulting in a Medium residual risk rating despite the high base score.

Integrating IT risk into ERM ensures that IT risk decisions are directly linked to business strategy and objectives, enabling leadership to prioritize risks that could impact critical business outcomes. This alignment is the primary benefit because it transforms IT risk from a technical concern into a strategic business driver, facilitating better resource allocation and governance.

Formal risk acceptance occurs when an organization decides to retain a risk because it falls within the defined risk appetite, while documenting the decision, assigning an owner, and scheduling periodic review. The hospital's actions match this pattern precisely. Mitigation would add controls, avoidance would remove the activity, and transfer would shift the impact to a third party; none of those occurred, so acceptance is the correct characterization.

By discontinuing the use of the third-party service, the company eliminates the risk entirely rather than reducing or accepting it. This is the definition of risk avoidance, where the activity giving rise to the risk is ceased. The decision is based on the residual risk being too high to be acceptable or cost-effectively mitigated.

The risk practitioner must first assess the impact of the control deficiency on residual risk because the finding may not represent a material risk to the organization. Without understanding the severity and likelihood of the risk, any remediation or reporting could be misprioritized. This aligns with the CRISC framework's emphasis on risk-based decision-making before action.

Connecting each IT risk to the business process and objective it can disrupt is business process mapping within risk identification. It shifts the conversation from technical faults to business consequences, enabling the hospital to prioritize risks that affect patient care and regulatory obligations. This linkage is what makes a risk register useful for decision making rather than a mere inventory of technical issues.

Implementing redundant hardware for critical components and conducting regular failover testing directly reduces the likelihood of a major outage by addressing the single point of failure exposed by the recent hardware failure. This is an immediate risk treatment that does not depend on the 2-year migration timeline, and it aligns with the institution's very low risk appetite for core banking disruption.

Spoofing in STRIDE refers to impersonating something or someone else to gain unauthorized access, such as using stolen credentials.

Organized crime groups are primarily motivated by financial gain and often have sophisticated technical skills to carry out attacks such as ransomware, data theft, or fraud.

A properly connected risk scenario must link a specific threat event to a quantified or clearly articulated business impact. Option D does this precisely: a DDoS attack (threat event) causes website unavailability for 4 hours (operational impact) resulting in $500,000 lost sales and customer churn (financial and reputational business impact). This chain from threat to measurable business consequence is what CRISC expects in risk scenario development.

The risk manager's decision to proceed with the launch despite residual risk exceeding the risk appetite, while committing to regular monitoring, is the definition of risk acceptance. In IT risk management, this acknowledges that the remaining risk is tolerable for business objectives, and the monitoring plan ensures any escalation is detected early. This is not a passive decision but an active, documented acceptance of the residual risk level.