Cyber Risk Assessment and Treatment

Introduction and Context

Cybersecurity decisions are fundamentally risk decisions. An organisation cannot eliminate every threat, protect every asset equally, or deploy unlimited controls. It must therefore determine what could go wrong, how probable and consequential each event may be, and which treatment is proportionate to the risk.

Cyber risk assessment provides a structured method for understanding exposure. Cyber risk treatment then converts assessment results into decisions such as avoiding an activity, reducing the likelihood or impact of an event, transferring part of the financial consequence, or accepting the remaining risk. These activities support confidentiality, integrity and availability, while also addressing privacy, safety, legal compliance, resilience and organisational reputation.

Risk assessment is not a one-time technical exercise. Assets, business processes, technologies, adversaries, regulations and vulnerabilities change continuously. A risk register, supported by accountable ownership and periodic review, provides an auditable record of decisions and outstanding exposure.

Learning Objectives

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

1. Identify information assets, business processes, threats and vulnerabilities.
2. Distinguish inherent, current and residual risk.
3. Estimate likelihood and impact using qualitative and quantitative approaches.
4. Construct and maintain a useful cyber risk register.
5. Select and justify avoidance, mitigation, transfer or acceptance treatments.
6. Explain the limitations, assumptions and governance requirements of risk models.
7. Apply the assessment process to a realistic organisational scenario.

1. Foundations of Cyber Risk

1.1 Risk, threat, vulnerability and control

A risk is the effect of uncertainty on objectives. In cybersecurity, it is commonly expressed as the possibility that a threat will exploit a vulnerability and cause harm to an asset, process or stakeholder.

A threat is a potential cause of an unwanted event. Threats may be intentional, such as ransomware, credential theft or fraud; accidental, such as misconfiguration or deletion; environmental, such as flood or fire; or systemic, such as a failure at a critical supplier.

A vulnerability is a weakness that can be exploited or triggered. Examples include unpatched software, excessive privileges, weak authentication, inadequate backup testing, insecure application design and insufficient staff awareness.

An asset is something valuable to the organisation. Assets include data, applications, devices, networks, cloud services, facilities, people, credentials, intellectual property, business processes and reputation. Asset value is not limited to purchase cost: a customer database may be valuable because of legal obligations, competitive advantage and the effect of disclosure on individuals.

A control is a measure that modifies risk. Preventive controls attempt to stop an event; detective controls identify it; corrective controls restore or repair operations. Controls may be technical, administrative, physical or contractual. Multi-factor authentication, security monitoring, incident response procedures, fire protection and supplier clauses are all controls.

1.2 The risk chain

A useful analytical chain is:

Asset or objective → threat event → vulnerability or enabling condition → consequence → control response

For example, a payroll database is an asset. Credential theft is a threat event. Absence of multi-factor authentication is an enabling weakness. Unauthorised alteration of salaries is a consequence. Multi-factor authentication, privileged-access management, transaction monitoring and approval workflows are controls.

This chain prevents a common error: listing technologies without explaining which risk they address. A firewall is not automatically an adequate treatment. Its value depends on the threat, architecture, configuration, monitoring and operating discipline surrounding it.

1.3 Inherent, current and residual risk

Inherent risk is the exposure before considering controls. Current risk is the exposure under controls that presently exist. Residual risk is the exposure remaining after a proposed treatment has been implemented. In some organisations, current and residual risk are distinguished explicitly; in others, residual risk refers to the accepted remainder after all planned controls.

The distinction is important because a risk may appear low only because strong controls are operating. If those controls fail, the underlying inherent exposure may be high. Risk assessments should record both the underlying scenario and the effectiveness and reliability of controls.

2. A Structured Risk Assessment Method

A practical assessment normally follows these stages:

1. Establish scope, context and risk criteria.
2. Identify assets, processes and dependencies.
3. Identify threats and vulnerabilities.
4. Analyse likelihood and impact.
5. Evaluate the result against risk appetite and criteria.
6. Record the result in a risk register.
7. Select treatment options and controls.
8. Assign ownership, deadlines and resources.
9. Verify implementation and reassess residual risk.
10. Monitor changes and communicate decisions.

This resembles the risk-management cycle used in frameworks such as ISO/IEC 27005 and is compatible with the NIST Risk Management Framework and NIST Cybersecurity Framework. Organisations should use a recognised framework where required, but should avoid treating framework terminology as a substitute for judgement.

2.1 Establishing context and criteria

Before scoring risks, define:

• the organisational unit, system, process or supplier in scope;
• assessment assumptions and exclusions;
• legal, regulatory and contractual obligations;
• risk appetite and risk tolerance;
• impact dimensions and rating scales;
• time horizon and assessment date;
• evidence sources and participants; and
• approval and escalation rules.

Risk appetite describes the broad amount and type of risk an organisation is willing to pursue or retain. Risk tolerance specifies acceptable variation around objectives. For example, an organisation may have little tolerance for exposure that could compromise safety or regulated personal data, while accepting more operational risk in a low-criticality development environment.

2.2 Asset and process identification

Asset identification should begin with business outcomes rather than an unstructured inventory of devices. Ask:

• What process or service must continue?
• What information does it create, use, transmit or store?
• Who owns it and who depends on it?
• Where is it hosted, including cloud and supplier environments?
• What are its confidentiality, integrity and availability requirements?
• What dependencies would prevent recovery?

A data-flow diagram, configuration-management database, cloud inventory, application catalogue and business-impact analysis can provide evidence. Classification should consider sensitivity, criticality, legal status, recoverability and concentration risk.

2.3 Threat identification

Threat sources may include cybercriminal groups, insiders, hacktivists, competitors, nation-state actors, ordinary users, suppliers and natural hazards. Threat analysis should consider capability, motivation, opportunity, access and persistence. A threat catalogue is useful, but workshops should also explore organisation-specific scenarios.

A threat scenario should be written clearly enough to analyse. For example: “An attacker obtains a privileged cloud credential through phishing and downloads customer records from object storage.” This is more useful than the isolated label “phishing,” because it identifies the asset, access path and consequence.

2.4 Vulnerability and control analysis

Vulnerability identification may use vulnerability scanners, penetration tests, code review, configuration assessment, audit findings, incident records, threat intelligence and interviews. A vulnerability identifier or severity score can support prioritisation, but it does not itself represent business risk. A critical software flaw on an isolated, well-monitored system may create less organisational risk than a moderate flaw in an internet-facing payment service.

Assessors should evaluate control design and control operation. A written backup policy is a design control; evidence that restores were tested successfully is evidence of operating effectiveness. Control effectiveness can be described as ineffective, partially effective, effective or highly effective, provided the definitions are documented.

3. Qualitative Risk Assessment

Qualitative assessment uses categories such as low, medium, high and critical. It is appropriate when data are incomplete, rapid decisions are needed, or consequences are difficult to express financially. It is not automatically less rigorous than quantitative assessment; rigour depends on transparent criteria, evidence and review.

3.1 Likelihood and impact scales

A five-level likelihood scale might be defined as follows:

A five-level impact scale should use organisational consequences rather than vague adjectives. It may include financial loss, service interruption, safety, privacy, regulatory and reputational dimensions. The highest material dimension is often used, although some organisations use weighted dimensions with governance approval.

3.2 Risk matrix

A common screening model is:

Here, R is the risk score, L is the likelihood score and I is the impact score. Both scales must be ordinal ratings, often from 1 to 5. The multiplication produces a prioritisation index; it is not a probability and has no currency or physical unit. It assumes that the organisation has defined the categories consistently and accepts the matrix as a decision aid.

For example, a scenario rated likelihood 4 and impact 5 receives a score of 20. A risk matrix may classify 1–4 as low, 5–9 as moderate, 10–16 as high and 17–25 as critical. These boundaries are policy choices, not universal scientific facts.

A matrix can conceal important differences. A risk rated 5 × 2 and one rated 2 × 5 both score 10, although one is frequent with limited harm and the other is unlikely with severe harm. Risk statements and treatment decisions must therefore accompany the score.

3.3 Strengths and limitations

Qualitative assessment is understandable to executives and non-specialists, supports workshops and works when reliable numerical data are unavailable. Its limitations include assessor bias, inconsistent interpretation of categories, false precision in scores and poor comparability between departments. Calibration workshops, documented definitions, evidence citations and independent challenge improve quality.

4. Quantitative Risk Assessment

Quantitative assessment expresses likelihood and consequence numerically. It is useful for investment decisions, insurance analysis, business cases and comparison of major alternatives, but it requires defensible data and explicit assumptions.

A basic single-loss expectancy model is:

SLE is single loss expectancy in currency, AV is asset value in currency, and EF is exposure factor, expressed as a proportion from 0 to 1. The model assumes that the selected asset value and percentage loss reasonably represent one occurrence. It may be unsuitable where impacts are nonlinear, cascading or difficult to monetise.

Annual loss expectancy is commonly estimated as:

ALE is annual loss expectancy in currency per year, and ARO is the annual rate of occurrence, measured as expected events per year. The model assumes that the average loss and event rate are meaningful over the chosen period. It is an expected-value estimate, not a guarantee or prediction of the exact annual loss.

Worked example

An online service has an estimated asset and business impact value of £400,000. A denial-of-service event is estimated to cause a 25% loss of that value for one occurrence. Historical and threat-intelligence evidence suggests an average of 0.4 such events per year.

SLE = £400,000 × 0.25 = £100,000

ALE = £100,000 × 0.4 = £40,000 per year

The result suggests an average annual loss of £40,000 under the stated assumptions. If a resilience service costs £18,000 per year and is expected to reduce the exposure factor to 0.08, the residual ALE would be:

SLE_residual = £400,000 × 0.08 = £32,000

ALE_residual = £32,000 × 0.4 = £12,800 per year

The estimated annual reduction is £27,200. A simple expected-value comparison indicates a gross annual benefit of £27,200 against an annual cost of £18,000, before implementation costs, secondary benefits, uncertainty and other risks are considered. It does not prove that the control should be purchased: management must also consider service-level obligations, dependencies, extreme events and non-financial consequences.

Quantitative models may use ranges rather than point estimates. Monte Carlo simulation can represent uncertainty by repeatedly sampling from probability distributions for event frequency and loss. Such analysis is valuable for major decisions, but output quality depends on input assumptions, correlations and the credibility of the distributions.

5. Risk Registers and Reporting

A risk register is a controlled record of identified risks, analysis, decisions and actions. A useful minimum structure is:

A strong risk statement follows the form: “Because of [cause or weakness], [threat event] may affect [asset or process], resulting in [consequence].” This avoids vague entries such as “cyberattack risk.”

The risk owner is accountable for deciding how the risk is managed and for ensuring that treatment is implemented. The owner need not be the person performing every technical task. A control owner may operate a specific safeguard, while internal audit or risk assurance provides independent challenge.

Risk registers should not become static spreadsheets. They should be linked to ticketing, vulnerability management, change management, incident management, supplier assurance and governance reporting where practical. Access should be controlled because registers may contain sensitive information about weaknesses.

6. Risk Treatment Options

After evaluation, management selects one or more treatments. Treatment should address the cause, likelihood, consequence or recovery capability and should be proportionate to risk.

6.1 Avoidance

Avoidance removes the activity, exposure or condition that creates the risk. Examples include discontinuing an insecure legacy service, refusing to collect unnecessary personal data, or choosing not to offer a high-risk feature. Avoidance can be effective but may reduce business opportunity or shift the risk elsewhere. A decision to avoid should confirm that the activity is genuinely stopped and that residual dependencies are addressed.

6.2 Mitigation or risk reduction

Mitigation reduces likelihood, impact or recovery time. Controls may include secure configuration, patching, network segmentation, encryption, multi-factor authentication, least privilege, secure development, backups, monitoring, incident response and staff training.

Controls should be selected using a defence-in-depth approach. For the privileged-cloud-credential scenario, prevention might include phishing-resistant authentication; restriction might include just-in-time privileges; detection might include unusual download alerts; and recovery might include credential revocation and tested restoration.

Treatment plans should specify acceptance criteria. “Improve security” is not measurable. “Enable phishing-resistant MFA for all administrative accounts by 30 September, verify coverage through an identity report, and test recovery access” is actionable and auditable.

6.3 Transfer or sharing

Transfer shares financial or operational consequences with another party. Examples include cyber insurance, contractual indemnities, managed security services and outsourcing. Transfer does not eliminate the underlying threat or the organisation’s accountability for personal data and regulatory duties. Policies may exclude poor configuration, aggregate events or war-related activity; contracts may be difficult to enforce. Due diligence and clear allocation of responsibilities are essential.

6.4 Acceptance

Acceptance is a deliberate decision to retain risk within approved tolerance. It should be informed, documented, time-bounded where appropriate and approved by an authorised person. Acceptance is not the same as inaction. The record should state the rationale, assumptions, monitoring arrangements, expiry or review date and trigger conditions for reconsideration.

6.5 Treatment selection

Treatment options may be combined. An organisation can mitigate technical exposure, transfer some financial consequences and accept a small residual risk. Cost-benefit analysis should include implementation, operation, maintenance, user impact, opportunity cost and control failure risk. Compliance requirements and fundamental rights may prohibit accepting certain exposures regardless of financial cost.

7. Governance, Ethics and Regulation

Cyber risk decisions affect individuals, customers, employees and society. Privacy risk assessment should consider data minimisation, purpose limitation, access rights, retention, confidentiality and the potential harm of discrimination, surveillance or identity theft. A technically secure system can still be ethically unacceptable if it collects unnecessary data or imposes disproportionate monitoring.

Regulatory obligations vary by jurisdiction and sector. Data-protection law, breach-notification requirements, critical-infrastructure rules, financial regulation, contractual commitments and records-management duties can change impact ratings and treatment deadlines. The assessment should identify applicable obligations rather than assuming that a framework alone establishes compliance.

Governance should ensure separation of responsibilities, evidence-based approval, escalation of high risks, conflict-of-interest management and periodic independent assurance. Senior leaders remain accountable for risk appetite and resourcing; technical teams provide evidence and implement controls; legal, privacy and compliance specialists interpret obligations.

8. Contemporary Practice and Technology

Cloud computing creates shared-responsibility issues: a provider may secure physical infrastructure and core services, while the customer remains responsible for identities, configurations, data and many applications. Software supply chains require assessment of dependencies, build pipelines, vendors and update mechanisms. Ransomware resilience requires more than backups; organisations should test restoration, protect backup credentials, segment recovery environments and define operational priorities.

Artificial intelligence can assist with asset discovery, anomaly detection, vulnerability prioritisation and analysis of large evidence sets. However, AI-generated assessments may contain fabricated evidence, hidden bias, excessive confidence or disclosure of sensitive information. Human review, provenance, access controls, model validation and clear accountability are necessary. AI should support, not replace, risk ownership and professional judgement.

Continuous monitoring is increasingly important. Useful indicators include overdue high-risk treatments, privileged-account coverage, restore-test success, mean time to contain incidents, exposed assets, vulnerability age and supplier-assurance status. Metrics should support decisions rather than reward superficial activity; counting patches alone does not demonstrate reduced business risk.

9. Illustrative Case Study: Northbridge College Student Portal

Background

Northbridge College, a fictional institution, operates a student portal containing identity records, assessment results, payment information and disability-support data. The portal is hosted in a public cloud and integrates with a third-party payment provider. The college has 18,000 students and a small security team.

Problem

An assessment identifies that administrative accounts use passwords without phishing-resistant MFA. A cloud storage bucket used for portal reports is incorrectly configured. Logging is incomplete, and restoration from backups has not been tested for nine months. A supplier contract contains general security language but no clear incident-notification deadline.

Analysis

The principal scenario is: “Because privileged cloud access lacks strong authentication and storage permissions are inadequately reviewed, an attacker may obtain administrative access and disclose or alter student records, causing privacy harm, regulatory consequences, service disruption and reputational damage.”

The asset is student information and the portal service. Threats include credential theft and misuse of privileged access. Vulnerabilities include weak authentication, configuration drift, limited monitoring and untested recovery. Existing controls include passwords, basic access groups and daily backups.

Using a five-point qualitative method, the team rates inherent likelihood as 4 (likely) and impact as 5 (almost severe), producing R = 4 × 5 = 20, classified as critical under the college’s policy. The score is not treated as a probability; the risk statement and evidence support the decision.

Approach and solution

The risk owner approves a treatment plan:

1. Enable phishing-resistant MFA for privileged accounts.
2. Apply least privilege and quarterly access reviews.
3. Enforce secure storage policies through automated configuration checks.
4. Centralise audit logs and alert on unusual administrative downloads.
5. Encrypt sensitive exports and reduce report retention.
6. Test restoration and document recovery objectives.
7. Add contractual incident-notification and assurance requirements.
8. Conduct an independent penetration test after implementation.

The college temporarily disables nonessential report exports, an avoidance measure that reduces exposure while controls are built. The residual assessment is likelihood 2 and impact 5, giving a score of 10, classified as high. Because impact remains high if a rare breach occurs, the data-protection officer and executive risk committee approve the residual risk only with monthly monitoring and a three-month review.

Outcome

After implementation, evidence shows complete privileged-account MFA coverage, successful restoration testing and automated detection of public storage exposure. The risk is not declared zero. The register records remaining dependency on the cloud provider, supplier assurance actions and the review date.

Learning points

The case demonstrates that risk is broader than a vulnerability score; controls must be linked to a scenario and verified in operation. Avoidance can provide immediate temporary protection. Residual risk requires explicit approval, and privacy, contractual and recovery considerations belong in the same decision process as technical controls.

10. Challenges and Best Practices

Common challenges include incomplete asset inventories, stale registers, overreliance on vulnerability severity, inconsistent scoring, optimism bias, lack of ownership, supplier opacity and treating compliance checklists as risk analysis. Extreme but plausible events may be ignored because their frequency is uncertain, while frequent low-level incidents may be underestimated because each event appears minor.

Best practice includes:

• begin with business services and information flows;
• use clear, evidence-based risk statements;
• define rating scales before scoring;
• distinguish inherent, current and residual risk;
• record assumptions and uncertainty;
• involve technical, operational, legal, privacy and business stakeholders;
• assign one accountable risk owner;
• make treatments specific, measurable and time-bound;
• validate controls through testing, not policy statements alone;
• reassess after incidents, major changes, new threats or control failures; and
• report trends and decisions to an appropriate governance forum.

No assessment model is objective merely because it contains numbers. Professional quality comes from sound scope, credible evidence, transparent assumptions, accountable decisions and effective follow-through.

Chapter Summary

Cyber risk assessment identifies what matters, how it may be harmed and which conditions enable harm. Assets include data, systems, services, people and processes; threats are potential causes of unwanted events; vulnerabilities are weaknesses; and controls modify exposure. Assessment begins by establishing context and criteria, then identifies assets, scenarios, vulnerabilities, existing controls, likelihood and impact.

Qualitative methods use defined categories and matrices to support prioritisation. The common score R = L × I is an index rather than a probability. Quantitative methods may estimate SLE = AV × EF and ALE = SLE × ARO, but results depend on data, assumptions and appropriate interpretation. A risk register provides traceability, ownership, treatment actions and review information.

Treatment decisions include avoidance, mitigation, transfer and acceptance. They may be combined, and none automatically eliminates accountability or residual exposure. Effective governance requires documented assumptions, authorised acceptance, privacy and regulatory consideration, control testing, continuous monitoring and reassessment. Risk management is therefore a continuing organisational discipline rather than a one-time technical report.

Key Terms

Asset: Something valuable that requires protection.

Asset value (AV): Estimated value or consequence basis used in a quantitative loss model.

Annual loss expectancy (ALE): Expected average loss per year, calculated in a basic model as SLE × ARO.

Annual rate of occurrence (ARO): Expected number of loss events per year.

Control: A measure that modifies risk.

Exposure factor (EF): Proportion of asset value lost in one event.

Impact: The consequence of a risk event on objectives or stakeholders.

Inherent risk: Risk before controls are considered.

Likelihood: The chance or frequency category assigned to an event.

Mitigation: Treatment that reduces likelihood, impact or recovery difficulty.

Residual risk: Risk remaining after treatment or existing controls.

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

Risk owner: Person accountable for managing and approving decisions about a risk.

Risk register: Controlled record of risks, assessments, treatments, owners and reviews.

Risk treatment: Action or decision that modifies risk.

Single-loss expectancy (SLE): Estimated loss from one occurrence.

Threat: Potential cause of an unwanted event.

Transfer: Sharing financial or operational consequences with another party.

Vulnerability: Weakness that can be exploited or triggered.

Review Questions

Short Answer Questions

1. Define a threat, vulnerability and control, and explain how they are related.
2. What is the difference between inherent risk and residual risk?
3. Why should a risk register identify a risk owner?
4. State the basic formulas for SLE and ALE and define their variables.
5. Give two reasons why a qualitative risk matrix may produce misleading results.

Long Answer Questions

1. Describe a complete cyber risk assessment process from establishing context through to monitoring residual risk.
2. Compare qualitative and quantitative risk assessment, including their assumptions, benefits and limitations.
3. Explain avoidance, mitigation, transfer and acceptance, using a practical example for each.
4. Discuss how privacy, regulation and ethics should influence cyber risk treatment decisions.
5. Explain why vulnerability severity alone is insufficient for prioritising organisational cyber risk.

Analytical / Application Questions

1. A service has an asset value of £250,000, an exposure factor of 0.30 and an annual rate of occurrence of 0.2. Calculate SLE and ALE, show the units, and explain one limitation of the result.
2. A university identifies a likely credential-theft scenario affecting a high-impact student-record system. Construct a complete risk statement and propose at least four controls covering prevention, detection and recovery.
3. A supplier offers cyber insurance but refuses to provide evidence of backup testing or a defined breach-notification period. Analyse whether transfer alone is an adequate treatment and recommend a governance decision.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a vulnerability?

A. A valuable information asset

B. A weakness that may be exploited or triggered

C. A person accountable for risk decisions

D. The financial loss from one incident

Correct Answer: B. A weakness that may be exploited or triggered

Question 2

An organisation rates likelihood as 4 and impact as 5 on its approved five-point matrix. What is the risk index?

A. 1

B. 9

C. 20

D. 25

Correct Answer: C. 20

Question 3

What does residual risk represent?

A. Risk before any controls exist

B. Risk transferred entirely to an insurer

C. Risk remaining after treatment or controls

D. The number of vulnerabilities found by a scanner

Correct Answer: C. Risk remaining after treatment or controls

Question 4

An asset value is £100,000 and the exposure factor is 0.2. What is the SLE?

A. £2,000

B. £20,000

C. £80,000

D. £500,000

Correct Answer: B. £20,000

Question 5

If SLE is £20,000 and ARO is 0.5 events per year, what is ALE?

A. £10,000 per year

B. £20,000 per year

C. £40,000 per year

D. £100,000 per year

Correct Answer: A. £10,000 per year

Question 6

Which treatment removes the activity or exposure creating the risk?

A. Acceptance

B. Transfer

C. Mitigation

D. Avoidance

Correct Answer: D. Avoidance

Question 7

Which is the strongest example of evidence that a backup control operates effectively?

A. A statement that backups are important

B. A draft backup policy

C. A successful documented restoration test

D. A high vulnerability score

Correct Answer: C. A successful documented restoration test

Question 8

Why is a risk score of 4 × 5 not a probability of 20%?

A. The score uses ordinal categories and is a prioritisation index

B. Likelihood can never be included in risk assessment

C. Impact always has a currency unit

D. Risk matrices calculate only asset value

Correct Answer: A. The score uses ordinal categories and is a prioritisation index

Question 9

Who is primarily accountable for deciding how an identified risk is managed?

A. The risk owner

B. The internet service provider

C. The vulnerability scanner

D. Any user who reports the risk

Correct Answer: A. The risk owner

Question 10

Which statement about cyber insurance is correct?

A. It removes the underlying threat

B. It guarantees regulatory compliance

C. It may share financial consequences but does not eliminate accountability

D. It replaces access control and monitoring

Correct Answer: C. It may share financial consequences but does not eliminate accountability