Certified in Risk and Information Systems Control CRISC (CRISC) — Questions 826–900

The identified risk is the lack of disaster recovery for a single-region cloud deployment. The best mitigation is to deploy across multiple cloud regions with automated failover, which directly addresses the availability and resilience gap by ensuring the application survives a regional outage. This is a preventive/architectural control that reduces both likelihood and impact of downtime.

Residual risk is defined as the risk that remains after controls have been applied to reduce the likelihood and/or impact of a threat exploiting a vulnerability. In this scenario, the high inherent risk was reduced to medium residual risk by the WAF and quarterly penetration tests, which is exactly the relationship described. This is the foundational risk equation in CRISC and ISO 31000.

Mandating a standardized risk assessment methodology ensures that all business units apply the same criteria, scales, and processes for identifying, analyzing, and evaluating risks. This eliminates methodological inconsistencies at the source, enabling the risk committee to produce truly comparable and reliable monitoring reports across the enterprise.

Business criticality expresses how important an asset is to the organization and therefore drives the impact dimension of risk. For a telemedicine platform used in urgent consultations, an availability loss can affect patient safety, regulatory standing, and reputation. Documenting this dependency allows the practitioner to assign a defensible impact rating during identification, which supports later prioritization and response.

The FAIR framework calculates ALE as Threat Event Frequency × Vulnerability × (Primary Loss + Secondary Loss). Here, 2 × 0.3 × ($500,000 + $200,000) = 2 × 0.3 × $700,000 = $420,000. This correctly accounts for the probability of a successful attack and the total loss per incident.

When residual risk remains above the risk appetite after initial risk assessment, the most appropriate next step is to implement additional controls to further reduce the risk to an acceptable level. This aligns with the risk treatment process where controls are selected and applied to lower the likelihood or impact of the risk event. Simply transferring, ignoring, or accepting the risk without further action would not address the gap between residual risk and risk appetite.

The exhibit shows a DMZ architecture where the internal network is separated from the DMZ by a firewall. A risk assessment would identify the potential for an attacker who compromises a DMZ host (e.g., a web server) to pivot through the firewall to the internal network, especially if firewall rules are overly permissive or if the DMZ host has a trust relationship with internal systems. This lateral movement risk is a classic and high-priority finding in such segmented environments.

When a risk is within appetite, it may be formally accepted with sign-off.

Enhanced monitoring and manual fallback procedures directly address the immediate risk of system failure during peak periods by providing early detection and a contingency plan to maintain critical financial operations. This response can be implemented quickly without the 18-month timeline and capital investment required for a full system upgrade, aligning with the CEO's request for a faster risk reduction.

Third-party dependencies must be identified and recorded regardless of the assurance a vendor provides. The firm should log the dependency and then assess it using the SOC 2 Type II report's scope, coverage period, complementary user entity controls, and exceptions, so that residual risk is judged realistically. Assurance evidence informs the assessment; it does not remove the dependency from the register or transfer the firm's accountability.

Historical transaction patterns and baseline deviations (B) are essential because alert thresholds must be calibrated to normal behavior to minimize false positives and false negatives. Without understanding typical transaction volumes, values, and frequencies, the monitoring solution cannot distinguish legitimate activity from suspicious anomalies, rendering alerts meaningless.

Given the extremely high downtime costs, the most appropriate risk response is risk reduction through implementing redundant systems. This directly addresses the critical system's availability requirement by eliminating single points of failure, thereby reducing both the likelihood and impact of downtime. Decommissioning the system (avoidance) would eliminate the business function entirely, which is typically not viable for a critical system, while insurance (transfer) only provides financial compensation after the loss, not preventing the operational impact of downtime.

Assigned responsibilities are a key component of an effective risk treatment plan because they ensure accountability for implementing specific risk mitigation actions. Without clear ownership, tasks may be delayed or overlooked, undermining the plan's execution. This aligns with the CRISC framework's emphasis on defining roles to operationalize risk response.

Disaster recovery plan execution (B) is a corrective control because it is activated after a disruptive event to restore normal operations. It directly addresses the impact of an incident by executing predefined procedures to recover systems and data, thereby correcting the damage caused by the outage or disaster.

Root cause analysis systematically identifies the weaknesses that allowed the breach, directly contributing to risk identification. Updating the risk register, implementing controls, and reviewing insurance are subsequent steps.

A control that is not executed as per its documented procedure indicates an operational failure. Even if the control design is sound, failure to follow the procedure means the control did not operate as intended, rendering it ineffective in mitigating the risk.

CSA involves defining scope, identifying controls, assessing effectiveness, gap identification, and reporting.

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.

The strongest finding is the confirmed existence of valid credentials held by a partner whose agreement has ended. That is a concrete threat-to-asset path affecting sensitive clinical trial data, and it must be documented and assessed. General concerns about role design, data sharing, or unstated authentication gaps are either design questions or unsupported assumptions compared with this active exposure.

The risk owner must formally acknowledge and accept the residual risk after the decision to accept has been made. This sign-off demonstrates that the risk owner is aware of the remaining exposure and agrees to the risk acceptance, which is a key governance step in the risk management process. Without this sign-off, the acceptance is not formally recognized, and accountability remains unclear.

The risk appetite statement sets a clear threshold of $5 million in acceptable operational losses per year. The project's potential loss of $8 million exceeds this appetite, so the risk practitioner should recommend risk treatment measures to bring the potential loss within the appetite. This aligns with the risk management principle of modifying risk to align with organizational risk tolerance before accepting or rejecting a project outright.

The first step in addressing an elevated KCI is to investigate the root cause of the exceptions to determine if they are due to rule misconfigurations, policy violations, or other issues before taking corrective action.

Incident reports are a primary source of IT risk identification because they provide direct evidence of past security events, such as malware infections, unauthorized access attempts, or system failures. By analyzing incident reports, risk practitioners can identify patterns, root causes, and control weaknesses that represent current or emerging risks. This historical data is essential for updating the risk register and prioritizing remediation efforts based on actual impact.

The most appropriate risk scenario because it follows the standard risk scenario structure: threat (attacker), vulnerability (weak authentication), impact (unauthorized access, data exfiltration, regulatory fines, reputational damage). It directly ties the technical weakness to a business consequence, which is essential for communicating risk to stakeholders. The scenario is specific to the application's internet-facing nature and sensitive data processing, making it actionable for risk treatment.

Expressing likelihood and impact as distributions acknowledges that estimates carry uncertainty, which is central to sound IT risk analysis. A point estimate of 15% implies false precision and hides tail risk that could threaten the core banking service. Distributions let the bank compare risk against tolerance, prioritize controls, and communicate exposure honestly to stakeholders without overstating confidence in a single number.

(Transfer) is correct because purchasing breach insurance transfers the financial risk of a data breach to an insurance provider. Option C (Avoid) is correct because disabling the APIs until they are secured eliminates the risk entirely by removing the vulnerable component. Option D (Mitigate) is correct because implementing a Web Application Firewall (WAF) reduces the likelihood or impact of an API-based attack without removing the API.

EDM03 — Ensure Risk Optimization is the COBIT 2019 governance objective specifically designed to ensure that the enterprise's risk appetite and risk tolerance are defined, communicated, and understood, and that risk is managed within those boundaries. It focuses on aligning risk management with enterprise objectives and ensuring that residual risk is acceptable.

Residual risk is the risk that remains after controls have been implemented to mitigate the original (inherent) risk. It represents the exposure the organization still carries and must consciously accept, transfer, or further mitigate. This is a core CRISC definition tested repeatedly.

The discrepancy between the vendor's security monitoring reports (showing no issues) and the company's internal monitoring (detecting anomalies in response times) suggests a potential control gap in the vendor's environment. Response time anomalies can indicate underlying security issues such as resource exhaustion, data exfiltration, or compromised systems that the vendor's monitoring may not be capturing. This misalignment warrants further investigation rather than dismissal.

Data sovereignty is a key concern in cloud computing risk because data may be stored in jurisdictions with different privacy laws. This means that data could be subject to legal requirements that conflict with the organization's own compliance obligations, such as GDPR or HIPAA.

Under GDPR, the maximum fine for non-compliance is the greater of €20 million or 4% of the organization's annual global turnover. Therefore, basing the estimate on annual global turnover directly aligns with the regulatory formula used by supervisory authorities, making it the most accurate and defensible quantification approach for potential fines.

A preventive control is designed to stop unauthorized access from occurring in the first place, which is exactly what an access control system does — it enforces authentication and authorization before granting access to sensitive data. Preventive controls are the primary defense against unauthorized access because they act before the security event occurs. This is the most appropriate control type for the stated objective.

A preventive control is designed to stop a risk event from occurring by implementing barriers or safeguards before the event can happen. For a high-risk process, this might include access control lists (ACLs) on a firewall that block unauthorized traffic, or input validation routines in an application that reject malformed data before it can trigger a buffer overflow. By proactively eliminating the threat vector, preventive controls reduce the likelihood of the risk event to zero for the protected path.

The first step in risk management is to validate the data and understand the root cause before taking action. A KRI exceeding its threshold may be due to false positives from a firewall change, so the practitioner must confirm whether the alert is genuine. Investigating the root cause ensures that any response is based on accurate information and addresses the actual issue, rather than reacting to a symptom.

The best way to address the risk that a vendor's security controls may not meet requirements is to include explicit security requirements in the contract and perform regular vendor audits. This contractual and assurance-based approach directly mitigates the risk by establishing enforceable obligations and ongoing verification. It aligns with risk management principles of treating risk through controls and monitoring rather than ignoring, transferring, or eliminating the business capability.

A KCI exception rate exceeding the threshold indicates a process failure, not necessarily a control failure. The control owner must first perform root cause analysis to determine whether the exceptions are due to misconfigured rules, policy violations, or environmental changes before taking corrective action. This aligns with the CRISC principle that control owners are responsible for monitoring and improving control effectiveness through investigation.

Annualized loss expectancy is the product of the loss from a single event and the estimated number of such events per year. Multiplying the $2,000,000 single-loss magnitude by the 0.4 annualized rate of occurrence yields an expected average annual loss of $800,000, which the hospital can use to compare against the cost of additional ransomware controls.

A single risk can belong to multiple categories; this is normal in risk categorization.

The risk manager must first quantify the risk gap between the required 99.99% availability (approximately 52.56 minutes of downtime per year) and the current 99.9% availability (approximately 525.6 minutes per year). This gap of 473.04 minutes per year establishes the magnitude of the risk exposure before any financial calculations (ALE, SLE, EF) can be performed, as those metrics depend on knowing the actual downtime that needs to be costed.

Residual risk is the risk remaining after controls are applied, and it is a function of both control design and control operating effectiveness. The scenario explicitly states the design is adequate but operating effectiveness is poor, meaning the controls exist on paper but are not functioning as intended in practice. Poor operating effectiveness therefore leaves the original inherent risk largely unmitigated, producing a high residual risk despite good design.

With residual risk above appetite and remediation requiring six months, the sound approach is to implement interim compensating controls, establish a remediation timeline, and obtain formal acceptance from the accountable business owner. This keeps exposure transparent and owned while respecting business continuity. Suspending service, manipulating ratings, or merely notifying the vendor do not appropriately manage the risk or satisfy governance and reporting expectations.

The Delphi technique is most appropriate for a new technology with limited historical data and high uncertainty because it leverages the collective judgment of a panel of experts through iterative, anonymous rounds to reach a consensus on risk likelihood and impact. This approach does not rely on historical loss data or predefined benchmarks, making it ideal for novel or emerging technologies where empirical data is scarce.

The board's statement explicitly articulates the organization's willingness to accept a moderate level of operational risk while having zero tolerance for compliance violations. This is the definition of risk appetite: the amount and type of risk an organization is willing to pursue or retain in pursuit of its objectives. Risk appetite is set at the strategic level and guides risk tolerance thresholds and risk criteria.

A preventive control is the most appropriate because it directly stops unauthorized access before it can occur. For a critical database, this could involve implementing database-level access control lists (ACLs), network firewall rules restricting traffic to specific IP ranges, or mandatory multi-factor authentication (MFA) on the database service. These mechanisms enforce the security policy at the point of entry, blocking the threat actor before any interaction with the data.

Executive risk reporting must be selective, business-oriented, and connected to appetite. Summarizing top risks by business impact and appetite alignment, with recommended actions, gives the committee what it needs to govern: which exposures matter, how they compare to tolerance, and what decisions are required. Full registers, scan counts, and incident-only reporting either overwhelm, mislead, or arrive too late.

In ISACA's risk scenario template, the 'threat event' component describes the specific action or occurrence that triggers risk — here, a user clicking a malicious link in a phishing email. This is the initiating event that, combined with the threat actor and vulnerable asset, produces the risk. The threat event is distinct from the threat actor (who), the vulnerability (what weakness), and the impact (what happens next).

DDoS success hinges on whether attack traffic can reach and overwhelm the target. Missing upstream mitigation lets traffic hit the origin unfiltered, and discoverable origin IP addresses let attackers bypass protective layers to strike directly. Together these conditions materially raise the likelihood of service disruption, while payment options, marketing spikes, and support outsourcing do not directly determine whether the attack succeeds.

A complete assessment scope requires knowing what must be protected and what could threaten it. Inventorying and classifying internal data repositories establishes the internal view, while mapping external threat sources and third-party attack surface establishes the external view. Prior findings, internal-only limits, and opinion surveys do not deliver this coverage, so they cannot fulfill the board's request.

Inherent risk is the level of risk before any controls are applied. The entry about the hurricane-prone data center with no redundancy and the entry about storing personally identifiable information with potential regulatory fines both describe raw exposures without reference to mitigating controls. The other entries mention implemented controls, control effectiveness reports, or recovery plans, which relate to residual risk after treatment.

When the external environment changes, the risk practitioner must first determine whether the previously approved risk response still keeps the risk within the organization's tolerance. That means reassessing the risk, the effectiveness of existing controls, and the alignment of the response with new regulatory expectations before recommending any change. This maintains evidence-based governance and gives the risk committee a defensible basis for deciding whether to accept, modify, or escalate the response.

The most likely reason for the discrepancy is that the CSA participants lacked objectivity. Control self-assessments are performed by process owners or staff who may have a vested interest in reporting favorable results, leading to biased or incomplete evaluations. In contrast, an independent audit applies objective testing procedures, which are more likely to uncover actual control failures that the CSA missed or downplayed.

A 100% pass rate for a detective control indicates that every time the control was tested, it successfully detected the condition or event it was designed to identify. This demonstrates the control is operating effectively, meaning it is functioning as intended and providing the expected level of assurance. For example, if the detective control is an intrusion detection system (IDS) that correctly alerts on all test attack patterns, a 100% pass rate confirms its detection logic and signature updates are working correctly.

IoT devices are frequently constrained by cost, size, and power, which limits CPU, memory, and battery. This directly restricts their ability to run strong encryption, host-based firewalls, secure boot, or frequent patching, expanding the attack surface. Limited processing power is therefore a structural characteristic that elevates cybersecurity risk.

Risk appetite defines the level of risk the organization is willing to accept and should guide performance, not be retrofitted to justify it. Before raising the threshold, the committee must determine whether improved third-party controls can reduce failures to within the existing limit. Adjusting appetite to match poor results would normalize the exposure, conflict with the regulatory finding, and weaken governance oversight.

Residual risk is only meaningful when it reflects validated control effectiveness across the full scope of the risk. The risk owner lowered the rating based on tokenization without confirming that legacy terminals were included, so the reported low residual risk was inaccurate. Risk response and reporting require evidence that controls operate as designed before risk ratings are adjusted downward, and audit findings should trigger reassessment of the affected register entries.

The risk register is the central repository for documenting identified risks, their assessed impact and likelihood, and the corresponding treatment plans (e.g., mitigate, accept, transfer, avoid). Its primary purpose is to provide a structured, living record that enables ongoing tracking, prioritization, and management of risk treatment activities throughout the IT risk management lifecycle.

Timeliness of information is a common challenge in risk reporting because risk data must be current to support effective decision-making. If reports are delayed, the organization may act on outdated risk profiles, leading to inappropriate responses. Real-time or near-real-time reporting is often required, but data aggregation and processing latency can introduce delays.

Risk score = 3 × 4 = 12, which falls in the high range (12-25).

Residual risk must be judged from current evidence about control effectiveness. An older certification says little about whether the encryption module still blocks today's exploits. Obtaining up-to-date scan results and patch records gives the team the factual basis to determine whether the remaining exposure is tolerable, which is the necessary first step before any treatment decision.

Continuous monitoring means ongoing, automated observation of controls and risk indicators at frequent intervals. Daily automated vulnerability scanning fits this definition because it runs repeatedly without manual intervention and provides near-real-time visibility into the control environment. The other options are periodic, point-in-time activities.

When a legacy system cannot be replaced for three years, the most effective risk treatment is to reduce the likelihood and impact of exploitation through compensating controls. Network segmentation limits lateral movement from the legacy system, and enhanced monitoring (e.g., SIEM with custom rules for anomalous traffic) provides early detection of compromise. This aligns with the ISACA risk treatment principle of risk reduction when avoidance or transfer is not feasible.

The risk register is the central repository that documents all identified risks, including their characteristics (e.g., likelihood, impact, risk rating), risk owners, mitigation plans, and current status. It is a key tool in the risk identification and assessment process, as defined in CRISC and ISO 31000.

Third-party remote access creates standing privileged exposure that must be constrained technically, not just contractually. Privileged access management with just-in-time elevation, credential vaulting, session brokering, and recording limits vendor reach to approved windows and produces attributable evidence. Policy signatures, standing admin accounts, and insurance certificates leave the actual access path uncontrolled.

The organization has a critical risk gap: the actual recovery capability (6 hours) exceeds the stated RTO (4 hours), meaning the business would incur $1M in losses (2 hours × $500K) before recovery completes. The risk owner's informal acceptance is insufficient for a financial institution processing high-value transactions; formal documentation and risk committee approval are required for governance and regulatory compliance. Presenting the gap enables informed decision-making on whether to accept the risk formally or invest in remediation (e.g., automating failover to meet the 4-hour RTO).

Integrating OT and IT networks creates a new attack path from the IT network to the OT network. Since OT systems often lack modern security controls and run legacy protocols (e.g., Modbus, DNP3), an attacker who compromises the IT network can pivot into the OT environment, potentially disrupting physical processes. This risk is prioritized because it introduces a direct, high-impact threat to safety and availability that did not exist before the integration.