Certified in Risk and Information Systems Control CRISC (CRISC) — Questions 526–600

CIS Benchmarks provide prescriptive, platform-specific secure configuration baselines for operating systems, mapping directly to configuration weaknesses. They satisfy the stem's configuration focus by detailing exact settings, registry values and service states to compare against, unlike vulnerability scanners that detect missing patches or generic threat feeds lacking hardening guidance.

The NVD enriches CVE identifiers with severity scoring, affected product mappings, and references, making it a structured and timely source for prioritizing newly disclosed weaknesses. It allows the practitioner to filter and rank vulnerabilities relevant to the cloud products in scope. Because it is maintained as a public reference with consistent data fields, it directly supports emerging-risk identification and comparison across many software components.

Mitigation through data localization controls directly addresses the legal requirement by ensuring data remains within required jurisdictions. This allows the ERP deployment to proceed while complying with laws. It is the most appropriate response because it reduces risk to an acceptable level without abandoning the business initiative.

TLS 1.2 or higher encrypts data while moving between systems, directly satisfying the policy's requirement for protecting transmissions. This is encryption in transit, distinct from encryption at rest, which protects stored data. The policy's scope — all data transmissions — maps precisely to data in motion, making this the control being enforced.

A risk register serves as the central record capturing each identified risk alongside its assessed likelihood and impact, plus the agreed response owner and action. This directly fulfils the register's primary purpose: maintaining a structured, auditable repository that supports ongoing risk monitoring and informed decision-making throughout the risk management lifecycle.

A risk management policy is the governing document that mandates the organization's approach to risk assessment, treatment, and reporting, satisfying the stem's requirement for a primary source. It establishes authority, scope, and responsibilities, unlike frameworks or procedures, which support implementation rather than define the overarching programme.

The DLP policy inspects email and endpoint channels but omits cloud storage applications, so credit card data can leave via Dropbox or OneDrive undetected. That coverage gap is the monitoring deficiency, since exfiltration through those sanctioned apps is neither blocked nor logged.

Criticality rating based on business impact links each asset to the processes it supports, letting risk assessors prioritise threats by potential operational and financial consequence. Other attributes such as location or owner inform exposure but do not directly quantify risk severity.

Risk mitigation involves implementing controls to reduce the likelihood or impact of a risk. Surveillance systems deter theft and increase detection, while background checks reduce the likelihood of hiring individuals prone to theft. These actions directly lower the risk of inventory shrinkage, making this a clear example of mitigation.

Adding a risk identification task to each sprint backlog and reviewing risks in retrospectives embeds risk work into existing Agile ceremonies, keeping it iterative and continuous. This satisfies the stem's requirement to align with Agile principles while ensuring risks are identified every sprint.

Formalizing the risk treatment plan and including the compensating controls in the risk register is the best action. It documents the residual risk as medium and satisfies the requirement for a response plan within 30 days.

A major IT infrastructure change alters the threat landscape, vulnerabilities and control environment, invalidating prior assessment assumptions. This triggers an out-of-cycle assessment because the existing risk profile no longer reflects the operating environment, satisfying the stem's need for the strongest trigger indicator.

CSAs involve business owners evaluating control effectiveness, which is essential for monitoring.

Insider threat involving privileged financial access cannot be proven immediately, so additional monitoring and restrictions contain the risk while evidence is gathered. This satisfies the need for a proportionate response that limits exposure without prematurely accusing or removing the employee.

Legacy firmware often cannot accept vendor patches, leaving known vulnerabilities permanently exploitable on plant-floor sensors with long service lives. This satisfies the stem's constraint of identifying the most significant risk, since unpatchable devices sustain exposure that segmentation or monitoring alone cannot remediate.

Residual risk falls below inherent risk because preventive, detective, and corrective controls are all designed adequately, yet weak operating effectiveness from inconsistent patching leaves meaningful exposure unaddressed. Design adequacy alone cannot reduce risk to acceptable levels; the controls must actually function as intended, so significant residual risk persists.

A SOC 2 Type II report independently attests that controls over security, availability and confidentiality operated effectively across a review period, giving assurance proportionate to the critical vendor's access to sensitive customer data and satisfying the risk-appetite requirement for validated third-party control evidence.

Risk mitigation reduces the likelihood or impact of a risk through controls. Implementing a WAF and conducting penetration tests are detective and preventive controls that lower the probability of exploitation and the potential damage, aligning with mitigation.

Bridging IT and OT dissolves the air gap that previously isolated industrial control systems. Each newly reachable OT device, protocol and service becomes an additional entry point, so the attack surface expands from enterprise IT into operational technology, exposing safety-critical processes to IT-borne threats.

Transfer shifts the financial consequence of a risk to a third party. Cyber insurance does exactly this: the insurer absorbs covered losses in exchange for premiums, leaving the organisation's residual exposure reduced rather than retained, avoided, or mitigated.

Hacktivists are driven by political, ideological or social agendas, and they frequently deface or disrupt government, military and activist-related systems to publicise their cause. Unlike financially motivated cybercriminals or state-sponsored actors, their primary motivation is ideological, matching the stem's political-ideology and government-target criteria.

Static thresholds left unchanged for 18 months no longer reflect shifted transaction patterns, so the alerts themselves are mis-calibrated. Root cause analysis identifies which rules and thresholds generate the false positives, letting the team recalibrate detection precisely rather than adding headcount it does not have.

A former employee who still holds valid access is an internal threat source because the actor has or had trusted access to bank systems. Insider threats include malicious, negligent, and compromised insiders, and the terminated employee with a live credential fits the malicious or negligent insider category. This directly affects the likelihood assessment for unauthorized access scenarios.

A 60% reduction on the $500,000 ALE yields $300,000 in avoided loss. Subtracting the $80,000 annual control cost gives a net benefit of $220,000, satisfying the stem's requirement to quantify risk reduction minus control cost.

Malicious insiders act with deliberate intent to steal data, sabotage systems or abuse privileged access for gain. This satisfies the stem's requirement for an insider threat type, contrasting premeditated action with accidental or coerced behaviour.

Patch lag measures elapsed time between patch release and deployment, rising before exploitation occurs, so it leads vulnerability risk rather than reporting it afterwards. This satisfies the KRI requirement for a leading indication, unlike lagging metrics such as confirmed exploit counts.

Residual risk is the exposure remaining once implemented controls have reduced inherent risk, so it directly satisfies the stem's scenario of a risk owner calculating exposure after controls. It reflects control effectiveness rather than the untreated threat, and must be compared against the risk appetite to decide whether further treatment is required.

The risk register catalogues each identified risk with its owner, likelihood, impact and response, forming the evidentiary core that the rest of the report analyses. Without it, findings cannot be traced or tracked, so it satisfies the stem's key-component requirement.

Declining to enter a new market eliminates the exposure entirely rather than reducing or transferring it, satisfying the stem's requirement for risk avoidance. Unlike mitigation, which lowers likelihood or impact, or acceptance, which retains the risk, avoidance removes the underlying activity generating the threat.

The control lowers annualised loss expectancy by $400,000 ($500,000 − $100,000), then subtracts its $150,000 annual cost, giving a net benefit of $250,000. This satisfies the stem's cost-benefit constraint by quantifying residual risk reduction against control expenditure, confirming the investment yields positive value.

The risk practitioner's role is to assess whether the proposed risk response (WAF with virtual patching) effectively mitigates the identified risk to a level that aligns with the organization's risk appetite. This involves analyzing the control's expected effectiveness, cost, and impact on residual risk. The practitioner does not implement controls or accept risk unilaterally; rather, they provide guidance to ensure the response is appropriate and aligned with business objectives.

Availability at 99.2% breaches the 99.5% KRI threshold for two consecutive months, so the indicator has been triggered. Escalating to the risk owner and performing root cause analysis converts the breach into assessed, actionable risk response rather than passive monitoring.

The control costs $1.9 million but only reduces expected loss by $1.8 million, producing a negative net benefit of $100,000 per year. Spending more than the expected loss avoided is not cost-justified, so the practitioner should advise against funding it and ensure the $600,000 residual ALE is formally accepted by the appropriate risk owner with documented rationale.

Risk treatment is the deliberate selection and implementation of controls that modify likelihood or impact. Database activity monitoring detects anomalous access while least-privilege enforcement reduces the chance that compromised accounts can reach sensitive records, directly lowering the likelihood component of the registered risk. This is a concrete, targeted control response rather than documentation or measurement activity.

Outsourcing shifts the financial impact of data centre failures to the third party, satisfying the stem's need to reallocate risk ownership. Unlike risk avoidance, which eliminates the activity, or mitigation, which reduces likelihood, transfer moves the consequence to another party via contract.

Risk identification requires evaluating threat sources in terms of capability, intent, and opportunity relative to the organization's own assets. The CERT report establishes general activity, but relevance to the bank depends on whether the group can realistically reach and exploit the mobile payment APIs. This asset-centric assessment determines if the threat is material and warrants entry into the risk register.

Threat modelling systematically enumerates threats, attack vectors and weaknesses against the database's architecture and data flows, exposing data-exposure scenarios before migration. It satisfies the stem's requirement for a primary risk identification technique by revealing threats that generic checklists would miss.

KRIs tied to strategic objectives ensure monitoring reflects risks that actually threaten the organisation's goals, rather than isolated technical metrics. This alignment keeps the cloud programme's risk reporting meaningful to leadership and drives relevant control decisions.

Discriminatory outcomes breach fair-lending legislation and expose the organisation to enforcement action and litigation. Bias arises from unrepresentative training data or proxy variables, so testing for disparate impact across protected groups is a governance control that directly addresses the stem's regulatory oversight constraint.

The plan includes encryption, access restrictions, and backups, all of which are controls designed to reduce the likelihood and impact of a data breach. These actions are characteristic of risk mitigation, where the organization takes steps to lower risk to an acceptable level while continuing the business activity. The strategy is clearly mitigation.

The control reduces the $200,000 ALE by 85%, giving a mitigated ALE of $30,000 and an $170,000 loss reduction. Subtracting the $50,000 annual cost yields a net benefit of $120,000, satisfying the cost-benefit comparison the stem requires.

A 60% reduction of the $2.4 million ALE equals $1.44 million in avoided loss. Subtracting the $600,000 annual cost yields a net benefit of $840,000, which is positive and therefore economically justified. This quantitative comparison directly answers the CFO's request for justification and supports approval.

Residual risk is what remains after controls are designed and operating. Installing database activity monitoring, encryption at rest, and quarterly access reviews reduced the likelihood and impact of the identified threat, so the re-rated medium value reflects the remaining exposure. CRISC practitioners use residual risk, not inherent risk, to judge whether the response brings the risk within the organization's stated tolerance.

The qualified opinion signals a specific control weakness, so the practitioner should evaluate how that weakness affects the logistics firm's data and systems. Implementing compensating controls, such as additional monitoring or restricting privileged access, reduces exposure while the provider addresses the root cause. This response is proportionate, risk-based, and maintains service continuity while holding the provider accountable.

An SSDLC embeds security training, mandatory code reviews and automated security testing into development, catching flaws like SQL injection before release. This treats the root cause of the missed vulnerability, reducing likelihood within the 30-day policy.

The shared responsibility model splits security duties between provider and customer, so assessing only one side leaves gaps. Mapping controls to each party's obligations and evaluating both ensures coverage of the actual division of accountability in the public cloud.

The risk owner is accountable for the overall management of a specific risk, including making decisions about risk treatment, ensuring controls are in place, and monitoring the risk over time. In this scenario, the risk owner for the outdated encryption risk must decide whether to accept, mitigate, transfer, or avoid the risk and ensure that decision is documented. This aligns with CRISC's emphasis on clear ownership and accountability.

Basing risk treatment decisions on clear, prioritised findings demonstrates that assessment outputs actually drive remediation choices, linking identified risk to action. This outcome confirms the process produces usable, ranked information rather than documentation alone, satisfying the stem's effectiveness criterion.

Normalizing all unit ratings onto one defined scale is the prerequisite for valid aggregation, because ratings expressed on incompatible scales cannot be compared or summed meaningfully. Documenting the conversion criteria preserves traceability and lets reviewers challenge the mapping. This directly addresses the scenario's core problem of three different likelihood scales feeding one enterprise register.

Detective controls are designed to discover and flag that a risk event has already happened, through logs, alerts, or monitoring. Unlike preventive controls, which block events before they occur, detective controls satisfy the stem's requirement of identifying that a risk event has taken place.

Misconfigured log forwarders are a common cause of log loss.

Changes introduce new risks and require reassessment.

Inherent risk reflects impact and likelihood before controls. A database supporting multiple business applications has high business criticality, so its failure causes widespread operational disruption, making this the dominant factor when rating inherent risk, ahead of technical failover gaps.

When synchronization fails or is misconfigured, accounts disabled on-premises may remain active in the cloud, and terminated users may retain access. This creates unauthorized access paths to cloud resources. In a hybrid model, synchronization integrity is foundational to access control, making this a high-priority risk that can undermine the entire IAM control set.

Regular security awareness training reaches all employees, embedding risk recognition into daily decisions and behaviours. This directly builds the shared understanding and accountability a risk-aware culture requires, satisfying the initiative's aim of shifting attitudes organisation-wide rather than relying on isolated controls.

Risk mitigation involves implementing controls to reduce the likelihood or impact of a risk. By deploying a cloud-based DDoS mitigation service, the firm adds a control that scrubs malicious traffic, thereby reducing the chance of downtime and lessening the impact of an attack. This aligns with the definition of risk mitigation, as the risk is still present but its effect is diminished.

Hacktivists act primarily to advance political, social, or ideological causes, using attacks such as defacement and data leaks for publicity rather than profit. Unlike organised crime or insiders, their motivation is ideological, making them the threat actor most likely driven by ideology instead of financial gain.

ARO is derived by dividing ALE by SLE: $500,000 ÷ $100,000 = 5, meaning the loss event is expected five times annually. This satisfies the quantitative relationship ALE = SLE × ARO, so an ARO of 5 reconciles the given figures.

Lack of encryption for data at rest is a technical vulnerability that could lead to data leakage if the storage is compromised. It is a weakness in the system's design or configuration. This directly relates to the risk of unauthorized disclosure of customer data. Therefore, it is a valid vulnerability that the risk practitioner should identify.

Cyber insurance shifts the financial impact of breach losses to an insurer, which is risk transfer. The organisation retains the risk itself but compensates losses externally, satisfying the definition of transfer as a risk treatment.

The indemnification clause shifts the financial consequence of a breach from the e-commerce company to the payment processor, which is the defining characteristic of risk transfer. The underlying risk of a breach still exists and the company still faces reputational harm, but the monetary loss is contractually assigned to another party. Recording this as transfer correctly reflects the response strategy in the register.

Risk transfer shifts the financial consequences of a risk to a third party, typically through insurance or outsourcing. By purchasing business interruption insurance, the firm transfers the financial loss from a hurricane to the insurer. The risk itself remains, but the financial impact is borne by another party, making this the correct classification.

The organization has already exceeded its stated downtime appetite, and the absence of root cause analysis means the underlying causes remain unknown. Before changing controls or reporting to the board, the practitioner needs to understand whether the two events stem from a common weakness. Root cause analysis provides that evidence and is the logical first step in determining an appropriate risk response.

When residual risk exceeds the risk appetite, it is outside the organization's tolerance. The risk manager should escalate to senior management, who have the authority to decide on further risk response, such as accepting the risk, implementing additional controls, or discontinuing the activity. This aligns with CRISC's emphasis on risk governance and ensuring risk is managed within appetite.

Scenario analysis explores plausible future states arising from new technologies, exposing risks with no historical data. It directly addresses emerging risks by reasoning about uncertainty rather than extrapolating past incidents, which is the constraint the question imposes.

Concentration and lack of redundancy are inherent characteristics of the operating model, not controls. If the provider suffers an outage or fails, payroll cannot run and employees go unpaid, which is a business impact that exists independent of any protective measure. This dependency is therefore an inherent risk factor that must be captured before evaluating the vendor's resiliency controls or the organization's contingency arrangements.

After analyzing inherent risk and evaluating controls, the next step is to determine residual risk, which is the risk remaining after controls. Comparing residual risk to the organization's risk appetite informs whether additional treatment is needed. This step is essential for making risk-based decisions and for communicating the risk position to stakeholders.

Risk identification systematically uncovers threats, vulnerabilities and existing controls before incidents occur, so weak authentication on the critical database would have been surfaced here. It satisfies the stem's requirement to determine which assessment step should have detected the vulnerability, preceding risk analysis and evaluation, which merely assess likelihood and impact of already-identified risks.

Fault tree analysis starts from a defined undesired top event and works backward through logic gates to show how combinations of lower-level failures cause it. With sparse historical data, it structures expert judgment about causal pathways and yields a visual model of how component failures combine, which directly matches the stakeholder need to resolve disagreement about failure propagation in the mobile banking feature.

A risk register is the central record capturing each identified risk together with its assessment results and chosen responses, enabling tracking and ownership over time. This supports the policy requirement by giving management a single, auditable view of risk status and treatment progress.

A DLP solution tuned too broadly flags legitimate activity, producing excessive false positives. Analysts then desensitise to alerts, so genuine data-loss incidents are overlooked — a risk introduced by the control itself, not by the threats it mitigates.

Automated security scanning embeds static and dependency analysis directly into the CI/CD pipeline, so vulnerabilities are flagged at commit or build time rather than after deployment. This satisfies the stem's requirement to detect code flaws early in the development lifecycle, before artefacts reach production.

Documenting the outdated encryption algorithms in the risk register with a remediation timeline satisfies the risk owner's obligation to record and track identified risk. The register captures the finding, while the assigned timeline ensures accountability for treating the cryptographic weakness, aligning with CRISC risk response and monitoring practise.

Incident logs and access monitoring reports show how controls performed against real events, including blocked attempts, anomalous access patterns, and detected violations. This operational evidence complements audit and penetration testing by revealing detective and responsive control behavior over time. Trends such as recurring failed logins from unusual locations can indicate control gaps that a point-in-time test might not surface, strengthening the residual risk determination.

Threat capability and motivation are core likelihood drivers. A well-resourced actor with sector-specific intent is more likely to attempt and succeed at exploiting ICS weaknesses. This raises both the frequency of attempts and the probability of success, making it a legitimate factor that increases the likelihood of a threat event in the assessment.