4. Cyber Risk Assessment and Decision Models

Introduction and Context

Cybersecurity decisions are rarely made under conditions of complete information. An organisation may know that an important system is exposed to the internet, that vulnerabilities exist, and that criminal groups are active, yet still need to decide whether to patch immediately, redesign the system, purchase insurance, accept the exposure, or transfer the activity to a third party. Cyber risk assessment provides the disciplined reasoning required to make such choices.

Risk assessment is more than the production of a risk score. It is an evidence-based process for understanding what may be harmed, how harm may occur, how probable the event is, what consequences may follow, and which treatment is proportionate to the organisation’s objectives and risk appetite. In applied cybersecurity practice, assessment must connect technical observations with business consequences. A critical vulnerability on an unused test server may be less urgent than a moderate weakness in an identity service supporting payroll and privileged access.

This chapter develops a practical and analytical approach to cyber risk assessment. It examines assets, threats, vulnerabilities, likelihood, impact, risk registers, attack trees, scenario analysis, qualitative and quantitative methods, FAIR concepts, and cost-benefit reasoning. It also considers uncertainty, governance, ethics, automation, and the professional judgement required when models cannot provide precise answers.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain the relationships among assets, threats, vulnerabilities, likelihood, impact, and risk.

2. Construct a defensible qualitative risk assessment and risk register.

3. Apply attack trees and scenario analysis to cyber events.

4. Distinguish qualitative, semi-quantitative, and quantitative approaches.

5. Explain the main concepts of the FAIR model, including loss event frequency and loss magnitude.

6. Use expected-loss and cost-benefit reasoning to compare risk treatments.

7. Identify uncertainty, bias, ethical concerns, and common errors in risk analysis.

8. Translate assessment results into decisions for technical teams, executives, auditors, and regulators.

Risk as a Decision Concept

A useful starting point is the relationship:

Risk = likelihood of an adverse event × consequence of that event

This expression is conceptually helpful, but it should not be treated as a universal arithmetic law. Likelihood may be expressed as a probability, frequency, ordinal category, or informed estimate. Consequence may include financial loss, safety effects, legal exposure, operational disruption, reputational damage, privacy harm, or strategic disadvantage. In some settings, risk is represented as a function rather than a simple product because multiple dimensions of consequence cannot be reduced reliably to one number.

A risk statement should normally identify an asset or objective, a threat, a vulnerability or enabling condition, and a consequence. For example:

> Because the organisation’s remote-access service permits password-only authentication, a threat actor may obtain access through credential compromise, resulting in unauthorised access to research systems and interruption of laboratory operations.

This form is stronger than a statement such as “remote access is high risk,” because it makes the causal logic visible and supports a treatment decision.

Important Terminology

An asset is something of value to an organisation, including information, software, hardware, services, facilities, people, processes, identities, or trust relationships. Asset value depends on the business purpose and the consequences of loss, alteration, disclosure, or unavailability.

A threat is a circumstance, actor, event, or capability that could cause harm. Threats may be malicious, accidental, environmental, or organisational. A criminal group, an insider, a power failure, a supplier error, and a misconfigured deployment pipeline may all be relevant threats.

A threat actor is the person, group, organisation, or system capable of carrying out a harmful action. Motivation, capability, access, resources, and persistence influence the actor’s relevance.

A vulnerability is a weakness that can be exploited or otherwise contribute to an adverse event. Vulnerabilities may be technical, procedural, physical, human, architectural, or contractual.

An exposure is the condition that makes an asset or service reachable or susceptible to a threat. Exposure is not identical to vulnerability: an unpatched flaw that cannot be reached may present less immediate risk than a less severe weakness on an internet-facing service.

An attack surface is the collection of interfaces, identities, devices, applications, services, suppliers, and pathways through which an organisation may be attacked.

Likelihood describes the chance or frequency of an event within a defined period. A likelihood statement is meaningful only when the time horizon and assumptions are specified.

Impact is the magnitude of harm if an event occurs. Impact should be considered across relevant dimensions rather than being limited to direct financial loss.

Inherent risk is the level of risk before considering controls. Residual risk is the risk remaining after controls and treatments are taken into account.

A control is a safeguard that prevents, detects, responds to, or reduces the effect of an unwanted event. A control may be technical, administrative, physical, legal, or procedural.

Risk appetite is the amount and type of risk an organisation is willing to pursue or retain in achieving its objectives. Risk tolerance defines acceptable variation around a specific objective or risk limit.

From Assets to Adverse Outcomes

A credible assessment begins with an understanding of the asset and the business process it supports. Asset inventories are useful, but inventories alone do not reveal value. A database may contain ordinary operational records, sensitive personal information, or data essential to safety-critical decisions. Classification, ownership, dependency mapping, and business impact analysis help establish value.

The familiar confidentiality, integrity, and availability model remains useful, but it should be extended where appropriate. Privacy, authenticity, accountability, resilience, safety, and regulatory compliance may be material consequences. For example, manipulation of an industrial control parameter may be more dangerous than disclosure of the same system’s configuration. In a financial setting, integrity and non-repudiation may dominate confidentiality.

Threat identification should avoid producing a long, unprioritised catalogue. The assessor should ask which actors or events have both opportunity and plausible motivation. Threat intelligence, incident history, sector information, exposure data, interviews, and architectural analysis can inform the answer. However, the absence of known attacks is not evidence that an event is impossible; it may indicate limited visibility or insufficient reporting.

Vulnerability analysis should consider exploitability in context. Relevant questions include whether the weakness is reachable, whether authentication is required, whether exploit tools are available, whether compensating controls exist, whether exploitation would be detected, and whether the vulnerable component is connected to high-value assets. A vulnerability score can support analysis but cannot replace it.

Controls modify risk through different mechanisms. Preventive controls reduce the chance of an event. Detective controls may not prevent compromise but can reduce dwell time and loss magnitude. Corrective and recovery controls reduce the duration or consequence of disruption. The same control may have different effectiveness against different scenarios, so statements such as “encryption eliminates the risk” are generally unjustified.

Qualitative and Semi-Quantitative Assessment

Qualitative assessment uses descriptive categories such as low, moderate, high, and critical. It is valuable where data are scarce, decisions must be made quickly, or consequences are multidimensional. A well-designed scale defines each category. For example, “high likelihood” might mean that a plausible event is expected more than once in a specified period, while “high impact” might mean material operational disruption, serious regulatory consequences, or significant harm to affected individuals.

A likelihood-impact matrix combines categories to produce a prioritisation result. It is useful for triage, communication, and consistent governance, but it has limitations. The multiplication of ordinal labels can create false precision. The difference between “medium” and “high” is not necessarily equal to the difference between “low” and “medium.” Matrix results can also hide uncertainty and encourage teams to focus on ranking rather than treatment quality.

Semi-quantitative methods assign numerical values to categories, such as one to five. They can improve repeatability, but the numbers remain proxies unless supported by meaningful measurement. Organisations should document definitions, assumptions, confidence levels, time horizons, and escalation rules. A risk scored 12 because of “likelihood 3 × impact 4” should not be interpreted as having twice the risk of a score of 6 unless the method explicitly supports that inference.

A practical qualitative assessment process is as follows:

1. Define the scope, system boundary, time horizon, and assessment purpose.

2. Identify assets, owners, dependencies, and business objectives.

3. Develop plausible threat scenarios rather than isolated vulnerability lists.

4. Estimate inherent likelihood and impact using documented criteria.

5. Identify existing controls and estimate their effectiveness.

6. Determine residual risk and compare it with appetite or tolerance.

7. Record assumptions, uncertainty, evidence, owner, due date, and treatment options.

8. Review the result with accountable business and technical stakeholders.

Quantitative Reasoning and FAIR Concepts

Quantitative analysis expresses uncertainty using numbers, ranges, distributions, or frequencies. It is particularly useful when comparing major investments, estimating annualised loss exposure, setting insurance limits, or evaluating alternatives with significant financial consequences. It should not be used merely to make an assessment appear scientific.

The FAIR model, or Factor Analysis of Information Risk, provides a structured way to decompose risk. Its central logic distinguishes the frequency of loss events from the magnitude of loss. Loss Event Frequency (LEF) represents how often events that produce loss are expected to occur. It can be analysed through threat event frequency and vulnerability. Threat event frequency concerns how often threat agents act or come into contact with the target. Vulnerability reflects the probability that contact results in loss, considering resistance strength and threat capability.

Loss Magnitude (LM) represents the probable size of loss when an event occurs. It may include primary loss, such as response costs, restoration, business interruption, or replacement; and secondary loss, such as litigation, regulatory action, customer response, or reputational effects. A simplified annualised loss exposure can be expressed as:

Annualised Loss Exposure = Loss Event Frequency × Loss Magnitude

A realistic analysis normally uses ranges or probability distributions rather than a single estimate. For example, a scenario may have an estimated frequency between 0.1 and 0.3 events per year and a loss magnitude between $200,000 and $1.2 million. Monte Carlo simulation can combine these uncertainties to produce a distribution of possible annual losses. Decision-makers can then examine mean loss, percentiles, or the likelihood of exceeding a defined threshold.

Quantitative analysis requires disciplined assumptions. Analysts should distinguish observed data from expert judgement, avoid double counting effects, document dependencies among scenarios, and test how results change when assumptions vary. A sensitivity analysis may reveal that the decision depends mainly on one uncertain variable, such as the duration of an outage or the probability of regulatory enforcement.

The value of FAIR-like reasoning is not that it predicts the future precisely. Its value is that it forces explicit causal reasoning and makes uncertainty visible. It also provides a vocabulary for discussing risk with financial and executive stakeholders.

Attack Trees and Scenario Analysis

An attack tree models how an attacker might achieve a defined objective. The root represents the objective, such as “obtain unauthorised access to payroll data.” Branches represent alternative paths, while sub-branches represent conditions that must be combined. OR relationships indicate alternatives; AND relationships indicate that all required conditions must be satisfied.

For example, a path to unauthorised access might require obtaining valid credentials, bypassing multifactor authentication, and reaching an internal application. Another path might involve exploiting an exposed application and escalating privileges. Attack trees help identify control points and reveal that a single event may have several routes. They should not be confused with a complete prediction of attacker behaviour: creative, adaptive, and insider actions may not fit neatly into the model.

Scenario analysis complements attack trees by describing a plausible event in operational terms. A scenario should specify the initiating condition, threat actor or source, target, sequence of events, existing controls, detection and response assumptions, consequences, and time horizon. Scenarios are particularly useful for tabletop exercises, business impact analysis, incident response planning, and executive decision-making.

Good scenarios are specific enough to analyse but not so narrow that they become unlikely technical stories. “A cyberattack occurs” is too vague. “A compromised supplier account is used to access the software repository, insert malicious code, and disrupt customer deployments” provides a basis for estimating control performance and impact.

Risk Registers as Management Instruments

A risk register is not simply a spreadsheet of vulnerabilities. It is a management instrument that connects risk statements to owners, decisions, treatments, and review dates. A useful register may include:

• risk identifier and concise risk statement;
• affected asset, process, or objective;
• threat scenario and vulnerability or enabling condition;
• inherent likelihood and impact;
• existing controls and their effectiveness;
• residual likelihood, impact, and confidence level;
• proposed treatment, cost, dependencies, and expected risk reduction;
• accountable risk owner and treatment owner;
• target date, status, acceptance authority, and review trigger.

The risk owner is accountable for deciding how the risk will be treated; this is not always the same person as the system administrator or security analyst. Treatment options normally include mitigation, avoidance, transfer or sharing, and acceptance. Acceptance should be explicit, time-bounded where appropriate, and authorised at a level consistent with the organisation’s governance model.

Registers become ineffective when they are copied forward without reassessment, populated only by security staff, or used as evidence that risk has been managed merely because it has been recorded. They should be linked to architecture reviews, vulnerability management, procurement, audit, incident learning, and strategic planning.

Cost-Benefit Reasoning and Treatment Decisions

Risk treatment is an economic and governance decision, not a race to implement every available control. A treatment should be evaluated in relation to its expected risk reduction, implementation cost, operational effect, residual exposure, and strategic value.

A simplified decision rule compares the expected avoided loss with the cost of the treatment:

Expected Net Benefit = Expected Loss Reduction − Treatment Cost

Suppose a scenario has an estimated annual expected loss of $400,000. A proposed control is expected to reduce that exposure by 60 percent and costs $150,000 in the first year. The estimated avoided loss is $240,000, producing a simplified first-year net benefit of $90,000. This calculation is not sufficient by itself. The analyst should consider implementation risk, maintenance costs, non-financial benefits, dependencies, uncertainty, and whether the treatment introduces new risks.

Controls may be justified even when direct financial savings are uncertain. Legal duties, safety obligations, contractual commitments, human rights, and public trust can establish requirements that are not reducible to return on investment. Conversely, an expensive control may not be proportionate if a less costly design change provides comparable protection.

Decision analysis should compare alternatives rather than comparing one proposal with no action only. Options may include reducing exposure, improving detection, segmenting a service, changing a supplier, accepting a limited risk, or replacing the system. The best choice may be a portfolio of partial treatments rather than one perfect control.

Illustrative Case: Protecting a University Research Data Platform

Background

This illustrative case concerns Northbridge University, which operates a cloud-hosted platform containing research datasets, grant information, and collaboration records. The platform is used by faculty, students, external partners, and a central research administration team. It supports important projects but is not classified as a safety-critical system.

Situation and Problem

An assessment identified password-only access for some external collaborators, inconsistent account review, and an application programming interface that exposed limited metadata. The vulnerability scanner rated several components as moderate severity. A technology team proposed replacing the platform immediately at a cost of $900,000. The research office argued that immediate replacement would interrupt active projects.

Analysis

The assessment team reframed the issue as scenarios rather than a list of weaknesses. The principal scenario was compromise of an external collaborator account, followed by access to restricted datasets. A second scenario involved misuse of the metadata interface to enumerate projects and infer confidential research activity.

The team assessed the first scenario qualitatively as high residual risk because the platform contained valuable information, external identities were difficult to verify, and account review was inconsistent. Impact included confidentiality loss, research delays, notification obligations, and possible loss of partner confidence. The metadata scenario was assessed as moderate impact but relatively frequent because it required less privileged access.

An attack tree showed several routes to the primary objective: password reuse, phishing, dormant accounts, and token leakage. The tree also showed that immediate platform replacement would not eliminate all paths if identity governance remained weak.

A simplified quantitative estimate used a range rather than a single figure. The first scenario was estimated at 0.15 to 0.35 loss events per year, with loss magnitude between $300,000 and $1.5 million. The analysis identified substantial uncertainty around partner notification costs and project delays.

Approach and Strategy

Instead of replacing the platform immediately, the university adopted a staged treatment plan: multifactor authentication for external users, automated removal of dormant accounts, quarterly access recertification, token protection, API rate limiting, central logging, and a contractual review of partner responsibilities. A replacement decision was deferred for six months, subject to control effectiveness and a follow-up assessment.

The security team documented the assumptions in the risk register and assigned the research director as risk owner. Technical teams owned implementation, while the privacy office reviewed notification and data minimisation concerns. A tabletop exercise tested the response to a compromised collaborator account.

Outcome

The staged approach reduced the most plausible access paths while preserving continuity for active research. It did not reduce risk to zero, and the university retained a documented residual risk. The follow-up assessment focused on observed control performance rather than merely recording that controls had been installed.

Learning Points

The case demonstrates that vulnerability severity is not the same as business risk. Scenario analysis exposed multiple attack paths, while attack-tree reasoning showed that identity governance was more central than platform replacement alone. Quantitative ranges communicated uncertainty more honestly than a single annual loss figure. Finally, a risk register was useful because it connected analysis to accountable decisions and review conditions.

Limitations, Biases, and Common Errors

Risk assessments are vulnerable to anchoring, optimism bias, availability bias, confirmation bias, and pressure to produce a preferred result. A recent incident may cause assessors to overestimate similar events, while the absence of incidents may produce unjustified confidence. Technical teams may overemphasise vulnerability scores; executives may focus excessively on visible financial costs.

Common errors include treating a vulnerability catalogue as a risk assessment, using undefined likelihood scales, ignoring asset dependencies, double counting impacts, confusing control presence with control effectiveness, and failing to state the time horizon. Another error is presenting precise dollar figures that are unsupported by evidence. Estimates should show ranges, confidence, assumptions, and sensitivity where material.

Risk models can also become outdated. Changes in technology, suppliers, threat capability, regulation, business processes, and organisational structure can alter both likelihood and impact. Assessments should therefore be reviewed after major change, significant incidents, new threat intelligence, control failure, or a defined period.

Governance, Ethics, and Professional Responsibility

Cyber risk decisions affect employees, customers, research participants, citizens, and other groups. Ethical assessment requires attention to harms that may be distributed unequally or cannot be fully compensated financially. Privacy impact, discrimination, loss of autonomy, safety, and access to essential services should not be hidden inside a single aggregate score.

Assessors must preserve independence, protect sensitive information, and communicate uncertainty honestly. They should not manipulate categories to secure funding or suppress findings to avoid accountability. Governance frameworks should define escalation, acceptance authority, record retention, conflict-of-interest management, and review responsibilities. Legal and regulatory requirements may establish minimum safeguards, reporting duties, or evidence expectations, but compliance should not be treated as proof that all material risk has been addressed.

Digital Tools, Automation, and Emerging Practice

Modern assessment draws on asset-management platforms, vulnerability scanners, cloud-security tools, attack-surface monitoring, identity analytics, security information and event management systems, and governance, risk, and compliance platforms. Automation can gather evidence, detect configuration drift, calculate exposure changes, and trigger reassessment. It cannot reliably determine business impact without organisational context.

Machine learning may assist with anomaly detection, prioritisation, and pattern analysis, but automated risk scores can reproduce incomplete data or hidden assumptions. Generative AI may help draft scenarios or summarise evidence, yet analysts must validate outputs, protect confidential data, and maintain human accountability. Explainability is especially important when a model affects access decisions, employee monitoring, insurance, or regulatory reporting.

Emerging practice is moving toward continuous control monitoring, attack-path analysis, cloud and software-supply-chain risk assessment, cyber-resilience measurement, and integrated enterprise risk modelling. These developments improve timeliness, but they also increase the need for data governance and careful interpretation. More data does not automatically produce better decisions.

Best Practices for Applied Risk Assessment

A mature practice generally follows these principles:

• Begin with business objectives and critical services, not only technical weaknesses.
• Express risks as plausible scenarios with clear causal relationships.
• Define time horizons, scales, assumptions, and confidence levels.
• Combine technical evidence with business-owner and process knowledge.
• Use qualitative methods for structured prioritisation and quantitative methods when decision value justifies the effort.
• Model controls by their actual preventive, detective, response, and recovery effects.
• Compare several treatment options, including redesign, reduction, transfer, and acceptance.
• Assign accountable owners and review dates.
• Use ranges and sensitivity analysis when estimates are uncertain.
• Reassess after incidents, major changes, control failures, or material changes in threat conditions.
• Communicate differently to engineers, risk committees, executives, auditors, and affected communities without changing the underlying facts.

Chapter Summary

Cyber risk assessment is a decision discipline that connects assets and organisational objectives with plausible threats, vulnerabilities, likelihood, impact, controls, and consequences. Qualitative matrices support consistent prioritisation, while quantitative approaches express uncertainty through frequencies, loss magnitudes, ranges, and distributions. FAIR concepts separate loss event frequency from loss magnitude and help analysts explain causal assumptions. Attack trees reveal alternative paths to an attacker’s objective, and scenario analysis connects those paths to operational outcomes.

Risk registers become valuable when they record accountable ownership, evidence, residual risk, treatment choices, uncertainty, and review conditions. Cost-benefit reasoning helps compare treatments, but financial calculations must be supplemented by legal, ethical, safety, privacy, and governance considerations. Effective assessment is neither a vulnerability list nor a precise prediction. It is a transparent, revisable basis for proportionate action.

Key Terms

Asset: A resource, service, process, identity, or information object that has value to an organisation.

Threat: A circumstance, actor, or event capable of causing harm.

Threat actor: A person, group, organisation, or system capable of carrying out a harmful action.

Vulnerability: A weakness that may be exploited or contribute to an adverse event.

Exposure: The condition that makes an asset reachable or susceptible to a threat.

Attack surface: The collection of interfaces and pathways through which an organisation may be attacked.

Likelihood: The estimated chance or frequency of an adverse event within a specified period.

Impact: The magnitude and nature of harm resulting from an event.

Inherent risk: Risk before existing controls and treatments are considered.

Residual risk: Risk remaining after controls and treatments are applied.

Control: A technical, administrative, physical, legal, or procedural safeguard that modifies risk.

Risk appetite: The amount and type of risk an organisation is willing to retain or pursue.

Risk register: A governed record of identified risks, analysis, ownership, treatment, and review information.

Attack tree: A structured representation of alternative and combined paths to an attacker’s objective.

Scenario analysis: Examination of a defined plausible event, its sequence, controls, and consequences.

Loss Event Frequency: In FAIR analysis, the expected frequency of events that produce loss.

Loss Magnitude: In FAIR analysis, the probable size of loss when a loss event occurs.

Risk treatment: An action or decision intended to avoid, reduce, transfer, or accept risk.

Sensitivity analysis: Examination of how changes in assumptions affect an assessment result.

Review Questions

Short Answer Questions

1. Distinguish between a threat, a vulnerability, and an exposure.

2. Why is an asset inventory insufficient for determining cyber risk?

3. What is the difference between inherent risk and residual risk?

4. Define Loss Event Frequency and Loss Magnitude.

5. Identify two weaknesses of a simple likelihood-impact matrix.

Long Answer Questions

1. Explain how an organisation can move from asset identification to a defensible cyber risk statement.

2. Compare qualitative, semi-quantitative, and quantitative risk assessment approaches.

3. Explain how attack trees and scenario analysis complement one another.

4. Discuss the role of a risk register in organisational governance and decision-making.

5. Explain how cost-benefit reasoning should be used when selecting cyber risk treatments.

Analytical / Application Questions

1. An internet-facing application has a moderate vulnerability score but supports a critical identity service. Develop a risk scenario and identify the evidence needed to estimate likelihood and impact.

2. A proposed control costs $200,000 and is expected to reduce an estimated annual loss exposure of $500,000 by 40 percent. Analyse the simplified financial case and identify at least three non-financial factors that could affect the decision.

3. Construct a small attack tree for unauthorised access to a university research repository and identify two controls that would disrupt different branches of the tree.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes residual risk?

A. Risk before any controls are implemented

B. Risk remaining after controls and treatments are applied

C. Risk transferred entirely to an insurance provider

D. Risk that has not yet been entered into a register

Correct Answer: B. Risk remaining after controls and treatments are applied

Question 2

Why should a risk assessment use a scenario rather than only a vulnerability list?

A. A scenario connects a weakness to a threat path and business consequence

B. A scenario eliminates the need to identify assets

C. A scenario guarantees an accurate probability

D. A scenario makes controls unnecessary

Correct Answer: A. A scenario connects a weakness to a threat path and business consequence

Question 3

In FAIR terminology, Loss Event Frequency refers primarily to:

A. The financial cost of replacing damaged hardware

B. The severity category assigned by a vulnerability scanner

C. The expected frequency of events that produce loss

D. The percentage of controls that are operating effectively

Correct Answer: C. The expected frequency of events that produce loss

Question 4

In an attack tree, an AND relationship means that:

A. Any one branch is sufficient to achieve the objective

B. All specified conditions or steps are required for that path

C. The attack has already been detected

D. The asset has no exploitable vulnerability

Correct Answer: B. All specified conditions or steps are required for that path

Question 5

An organisation estimates an annual loss exposure of $400,000 and a control is expected to reduce it by 60 percent at a first-year cost of $150,000. What is the simplified expected net benefit?

A. $90,000

B. $150,000

C. $240,000

D. $250,000

Correct Answer: A. $90,000

Question 6

Which is the strongest risk statement?

A. The network is high risk

B. Patch the server immediately

C. A compromised supplier account may access the repository and insert malicious code, disrupting customer deployments

D. The vulnerability score is 8.2

Correct Answer: C. A compromised supplier account may access the repository and insert malicious code, disrupting customer deployments

Question 7

What is a major limitation of treating ordinal matrix scores as precise measurements?

A. Ordinal categories always require financial data

B. The numerical differences between categories may not have equal meaning

C. Matrices cannot be used for prioritisation

D. Matrices measure only confidentiality

Correct Answer: B. The numerical differences between categories may not have equal meaning

Question 8

Who is normally accountable for deciding how an organisational risk should be treated?

A. The vulnerability scanner

B. The risk owner

C. The external attacker

D. The help-desk operator in every case

Correct Answer: B. The risk owner

Question 9

Which practice most directly improves the credibility of quantitative risk analysis?

A. Reporting a single exact number without assumptions

B. Ignoring uncertainty to simplify executive communication

C. Using ranges, documenting assumptions, and conducting sensitivity analysis

D. Replacing business evidence with a higher vulnerability score

Correct Answer: C. Using ranges, documenting assumptions, and conducting sensitivity analysis

Question 10

Why should automated cyber risk scores be reviewed by human analysts?

A. Automation cannot collect any security evidence

B. Automated scores may reflect incomplete data and hidden assumptions

C. Human review always produces a lower risk score

D. Automated tools are legally prohibited from assessing risk

Correct Answer: B. Automated scores may reflect incomplete data and hidden assumptions