Security Risk Assessment and Decision-Making

Introduction

Information security risk assessment is the disciplined process of identifying what must be protected, determining what could harm it, estimating the significance of that harm, and deciding how risk should be treated. It connects technical security activities with organisational objectives. A firewall rule, access-control policy, backup system, or security awareness programme is valuable only when it addresses a meaningful risk and is proportionate to the organisation’s needs.

Risk assessment is not the same as predicting the future with certainty. Threats, vulnerabilities, business dependencies, human behaviour, and technology change over time. Consequently, a risk assessment is an informed decision-making activity based on evidence, assumptions, professional judgement, and available resources.

The process is relevant to confidentiality, integrity, and availability, as well as privacy, safety, legal compliance, reputation, and financial performance. It supports decisions such as whether to deploy multi-factor authentication, replace unsupported software, purchase cyber insurance, discontinue an unsafe service, or formally accept a residual risk.

Learning Objectives

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

• identify and classify information assets;
• distinguish threats, vulnerabilities, events, impacts, and risks;
• assess likelihood and impact using qualitative and basic quantitative methods;
• construct and maintain a risk register;
• select controls according to risk, feasibility, and organisational context;
• explain the treatment options avoid, mitigate, transfer, and accept;
• recognise residual risk, risk ownership, and review requirements; and
• incorporate legal, ethical, governance, and emerging technology considerations into risk decisions.

1. The Foundations of Information Security Risk

1.1 Asset, threat, vulnerability, event, and impact

An asset is anything of value to an organisation. Assets include databases, applications, laptops, cloud services, networks, buildings, intellectual property, business processes, employees, suppliers, and public trust. An asset may be valuable because of the information it contains or because operations depend on it.

A threat is a potential cause of harm. Threats may be intentional, accidental, environmental, or technical. Examples include ransomware operators, dishonest employees, power failure, fire, misconfiguration, software defects, and credential theft.

A vulnerability is a weakness that can be exploited or triggered. Examples include an unpatched server, excessive user privilege, weak password practices, inadequate backup isolation, or a supplier with poor security controls.

A threat event is an occurrence in which a threat acts against an asset, often through a vulnerability. For example, an attacker uses a stolen password to access a payroll database.

Impact is the consequence of a threat event. It may include financial loss, service interruption, privacy harm, regulatory sanctions, safety consequences, loss of evidence, or reputational damage.

Risk is the possibility that a threat event will produce harmful consequences, considered in relation to uncertainty. A useful conceptual model is:

Likelihood and impact must be defined using a stated scale. This is a model for prioritisation, not a universal physical law. It does not capture every dependency, uncertainty, or interrelationship, and multiplication of ordinal scores can create misleading precision. Organisations should therefore document their method and assumptions.

1.2 The CIA triad and wider objectives

The CIA triad describes three central security objectives:

• Confidentiality: information is available only to authorised people, processes, or systems.
• Integrity: information and systems remain accurate, complete, authentic, and protected from unauthorised alteration.
• Availability: authorised users can access systems and information when needed.

Modern risk assessments also consider authenticity, accountability, privacy, resilience, and safety. For example, an altered medical record is primarily an integrity risk, but it may also create safety and legal risks. A denial-of-service attack is an availability event, but it may cause financial and reputational impacts.

1.3 Risk appetite and risk tolerance

Risk appetite is the broad amount and type of risk an organisation is willing to pursue or retain in achieving its objectives. A public hospital may have very low appetite for risks that endanger patient safety. A start-up may accept greater operational uncertainty while testing a new product.

Risk tolerance is the acceptable variation around a specific objective or risk. For example, an organisation may tolerate no more than two hours of unplanned unavailability for a critical service. Appetite and tolerance should be approved by appropriate management rather than inferred solely by technical staff.

2. A Structured Risk Assessment Process

A practical assessment normally proceeds through the following connected activities:

1. establish scope, context, criteria, and stakeholders;
2. identify and value assets;
3. identify threats and relevant threat events;
4. identify vulnerabilities and existing controls;
5. estimate likelihood and impact;
6. determine and prioritise risk;
7. select treatment options and controls;
8. record decisions, owners, deadlines, and assumptions; and
9. monitor, communicate, and review the assessment.

This is iterative rather than strictly linear. A new vulnerability may reveal an omitted asset, and a proposed control may expose a previously unrecognised operational dependency.

2.1 Establishing scope and context

Scope defines what is being assessed. It may cover a whole organisation, a payment application, a cloud migration, a branch office, or a particular business process. Scope should identify boundaries, interfaces, locations, technologies, suppliers, regulatory obligations, and exclusions.

Important context questions include:

• What business objective does the system support?
• Which services are critical, and how long can they be unavailable?
• What information is processed, where is it stored, and who uses it?
• Which laws, contracts, policies, and professional duties apply?
• Who owns the risk and who has authority to approve treatment?
• What assumptions, constraints, and dependencies affect the assessment?

Poorly defined scope can create false assurance. An assessment of an online portal that excludes its identity provider, administrator accounts, APIs, and outsourced hosting environment is incomplete.

2.2 Asset identification and classification

Asset identification should combine interviews, document review, system inventories, network discovery, data-flow mapping, configuration management records, and supplier information. The objective is not merely to create a list of devices. It is to understand relationships and business value.

A useful asset record includes:

Classification schemes vary. A simple scheme may use Public, Internal, Confidential, and Restricted. Classification should guide handling requirements such as encryption, access review, retention, secure disposal, and incident escalation. Labels alone do not protect information; procedures and technical controls must enforce them.

2.3 Threat and vulnerability analysis

Threat analysis asks who or what could cause harm and how. Threat sources may be external attackers, insiders, criminals, competitors, careless users, suppliers, natural hazards, or system failures. Threat modelling methods such as attack trees, misuse cases, and structured threat catalogues can help identify realistic scenarios.

Vulnerability analysis examines weaknesses and exposure. Sources include vulnerability scanners, penetration tests, code review, audit findings, incident records, configuration assessments, vendor advisories, and interviews. A vulnerability is not automatically a high risk: its importance depends on exposure, exploitability, affected assets, existing controls, and likely consequences.

A useful scenario statement follows this pattern:

Because [vulnerability or condition] exists, [threat source] may perform [threat event] against [asset], causing [impact].

Example: Because a remote-access service permits password-only authentication, a criminal may use stolen credentials to enter the administration network, causing unauthorised access to confidential customer records and disruption of service.

2.4 Existing controls and control effectiveness

Controls are safeguards that modify risk. They may be:

• Preventive, such as access restrictions and secure configuration;
• Detective, such as logging, monitoring, and intrusion detection;
• Corrective, such as incident response and malware removal;
• Deterrent, such as disciplinary policies and visible monitoring;
• Recovery-oriented, such as tested backups and continuity arrangements; or
• Directive, such as policies, standards, and training.

Controls may also be administrative, technical, physical, or contractual. Assessment must consider whether controls are designed appropriately, implemented consistently, monitored, and tested. A written backup policy is not equivalent to recoverable, regularly tested backups.

3. Likelihood and Impact Assessment

3.1 Qualitative assessment

Qualitative assessment uses categories such as Low, Medium, High, or Very High. It is useful when reliable numerical data are unavailable or when speed and communication are important. A five-point scale may define likelihood as follows:

Impact should likewise be defined using organisational consequences rather than vague adjectives. Criteria may include financial loss, downtime, affected people, regulatory consequences, safety, and reputation. For example, an organisation might define a High availability impact as interruption of a critical service for more than eight hours, but another organisation may use a different threshold.

A simple scoring method is:

where R is the risk score, L is the likelihood score, and I is the impact score. If both scales range from 1 to 5, scores range from 1 to 25. A sample interpretation could be 1–4 Low, 5–9 Moderate, 10–16 High, and 17–25 Extreme. These bands are organisational conventions, not universal standards.

The method assumes that the chosen scores are meaningful and that multiplying them is acceptable for prioritisation. It should not be presented as an exact probability or monetary loss. Two risks with the same score may require different responses because one threatens safety, one affects legal compliance, or one is easier to treat.

3.2 Basic quantitative assessment

Where historical data and reasonable assumptions exist, annualised loss calculations can support comparison. The single loss expectancy is commonly represented as:

where SLE is the estimated monetary loss from one occurrence, AV is the asset value in currency, and EF is the exposure factor, expressed as a fraction between 0 and 1. The calculation assumes that the selected asset value and proportional loss estimate are appropriate for the scenario.

The annualised rate of occurrence represents the expected frequency per year, and the annualised loss expectancy is:

where ALE is expected annual loss in currency and ARO is occurrences per year. Units are consistent because currency × occurrences per year produces currency per year. These estimates are not guarantees. They may be unreliable when events are rare, data are sparse, impacts are difficult to monetise, or losses are correlated.

Worked example. A department estimates that a major data exposure would affect an information asset valued at £120,000. Experts estimate that one incident would cause loss equivalent to 40% of that value, so EF = 0.40. The single loss expectancy is:

SLE = £120,000 × 0.40 = £48,000

If the estimated frequency is 0.2 incidents per year, then:

ALE = £48,000 × 0.2 = £9,600 per year

This result should not be interpreted as permission to spend £9,600 automatically. Control cost, implementation feasibility, legal duties, risk appetite, uncertainty, and non-financial consequences must also be considered.

3.3 Inherent and residual risk

Inherent risk is the level of risk before considering controls. Residual risk is the risk remaining after controls are implemented or considered. A control should reduce likelihood, impact, or both, but no control eliminates all risk.

Residual risk must be explicitly compared with risk tolerance. If it exceeds tolerance, additional treatment or a higher-level decision is required. Risk registers should record whether a score describes inherent risk, current risk, or projected residual risk; otherwise, comparisons become misleading.

4. The Risk Register

A risk register is a controlled record of identified risks and decisions. It supports accountability, prioritisation, reporting, and follow-up. Typical fields include:

A strong risk statement is specific. “Cybersecurity risk is high” is too vague. “A compromised supplier account could be used to access the customer-support application, exposing customer contact data and interrupting service” identifies a scenario that can be treated and monitored.

The risk owner is accountable for deciding how the risk is managed and whether residual risk is acceptable. The control owner is responsible for implementing or operating a safeguard. These roles may be held by different people.

5. Risk Treatment and Control Selection

Risk treatment should follow the organisation’s criteria and should consider effectiveness, cost, usability, legal obligations, dependencies, and implementation risk. A control that creates excessive operational friction may encourage users to bypass it. A technically strong control that cannot be maintained is not a dependable control.

5.1 Avoid

Avoidance removes the activity, asset, exposure, or condition that creates the risk. Examples include discontinuing an unsafe service, refusing to collect unnecessary sensitive data, or not connecting a legacy system to the internet.

Avoidance can be highly effective but may prevent a business opportunity or require process redesign. It should be genuine: moving an activity to a supplier does not automatically avoid the risk; it may transfer or alter the exposure.

5.2 Mitigate or reduce

Mitigation reduces likelihood, impact, or both. Examples include multi-factor authentication, network segmentation, secure development, encryption, patch management, least privilege, tested backups, monitoring, incident response, and staff training.

Controls should be layered. For example, protection of a cloud application may involve identity controls, secure configuration, application testing, logging, backup, supplier assurance, and recovery exercises. The objective is not to purchase controls indiscriminately but to address the specific risk pathway.

5.3 Transfer or share

Transfer allocates some financial or operational consequences to another party. Examples include insurance, contractual indemnity, managed security services, or outsourcing. Transfer does not normally remove accountability for privacy, legal compliance, ethical conduct, or customer impact. Contracts must define responsibilities, notification timelines, evidence access, audit rights, service levels, and subcontracting conditions.

Insurance may cover specified financial losses but may exclude weak security practices, war-related events, unreported incidents, or regulatory penalties. It should therefore complement—not replace—security controls.

5.4 Accept or retain

Acceptance means knowingly retaining a risk within approved tolerance. It is legitimate when documented, informed, authorised, and reviewed. Acceptance is not the same as ignoring a risk or failing to act.

A valid acceptance record should state the risk, rationale, expected residual exposure, decision-maker, expiry or review date, and conditions that would trigger reconsideration. Acceptance may be time-limited while a longer-term control is funded or designed.

5.5 Treatment selection

A decision can be represented in a treatment plan:

Cost-benefit reasoning is useful, but legal duties and safety obligations may override a simple financial comparison. The cheapest treatment is not necessarily the most responsible treatment.

6. Governance, Law, and Ethical Decision-Making

Risk decisions occur within governance structures. Policies should define assessment frequency, approval authority, escalation thresholds, evidence standards, and reporting. Boards and senior managers require understandable information about material risks, not merely technical vulnerability counts.

Legal requirements vary by jurisdiction and sector. Depending on the organisation, relevant duties may arise from data-protection and privacy law, breach-notification rules, computer misuse legislation, records obligations, sector regulation, employment law, accessibility requirements, and contractual commitments. A risk assessment should identify applicable obligations and obtain qualified legal advice where interpretation is uncertain.

Privacy risk assessment should consider collection, purpose limitation, access, retention, sharing, international transfer, data-subject rights, and the possibility of harm to individuals. Security controls must not create unjustified surveillance or discriminatory outcomes. For example, employee monitoring should have a legitimate purpose, appropriate transparency, proportionality, access restrictions, and retention limits.

Evidence must be handled lawfully and ethically. Security testing requires authorisation and defined boundaries. Penetration testing without permission may itself constitute unlawful access. Incident records should be protected because they may contain personal data, credentials, or sensitive weaknesses.

7. Technology, Cloud, and Artificial Intelligence

Cloud computing changes responsibility rather than eliminating it. A provider may secure the underlying infrastructure while the customer remains responsible for identity configuration, data classification, access permissions, application security, and retention. Shared-responsibility arrangements must be verified in contracts and technical documentation.

Artificial intelligence can assist with asset discovery, anomaly detection, vulnerability prioritisation, control mapping, and analysis of large risk datasets. However, AI-generated assessments can reproduce incomplete inventories, biased assumptions, false positives, or fabricated explanations. Sensitive information should not be entered into an AI service without authorisation and appropriate data-protection safeguards. Human review, traceability, validation, and clear accountability remain necessary.

Automated prioritisation should not rely solely on a vulnerability score. Exposure, exploit availability, asset criticality, compensating controls, business context, and potential impact must also be considered. AI can support judgement; it should not silently replace the risk owner’s decision.

8. Applied Case: Illustrative Online Retailer Assessment

Background

The fictional organisation Northbridge Retail operates an online store. Its environment includes a customer web application, payment-service integration, fulfilment system, employee identity service, and cloud-hosted customer database. The retailer processes names, addresses, order histories, and payment-related tokens. The case is illustrative and does not describe a real organisation.

Problem

A review finds that administrative access to the cloud environment uses passwords without multi-factor authentication. Several administrators have broad privileges, logging is incomplete, and restoration from backups has not been tested for eighteen months. The business is preparing for a major seasonal sales event.

Analysis

The customer database and ordering service are high-value assets. A credible scenario is that a stolen administrator password enables unauthorised access to customer information or manipulation of orders. The likelihood is assessed as 4 (Likely) and impact as 5 (Very High), producing a current score of 20 on the organisation’s 1–25 matrix. The score is a prioritisation indicator, not a probability.

A second scenario concerns ransomware affecting the fulfilment system. Existing endpoint protection reduces likelihood, but untested backups create severe recovery uncertainty. Likelihood is assessed as 3 and impact as 5, producing a score of 15.

Approach and solution

Management assigns the identity risk to the Head of Technology and approves mitigation. Immediate actions include enforcing multi-factor authentication for privileged accounts, removing unnecessary administrator rights, reviewing service accounts, and monitoring privileged activity. The retailer also establishes emergency access procedures so that strong authentication does not prevent authorised recovery.

For resilience, the organisation creates protected backup copies, documents recovery priorities, and performs a restoration exercise before the sales event. It updates supplier and cloud agreements to clarify incident notification, evidence access, and responsibilities. A privacy and legal review confirms notification and record-keeping requirements.

After implementation, the identity scenario is reassessed as likelihood 2 and impact 5, giving a residual score of 10. The impact remains high because a successful compromise would still be serious. The risk owner approves the residual risk temporarily, subject to quarterly access reviews, continuous logging, and a review after the sales period.

Outcome and learning points

The assessment converts general concern into prioritised action, assigned ownership, measurable controls, and a review timetable. It also demonstrates that mitigation does not necessarily lower impact; it may primarily reduce likelihood. The case highlights the importance of privileged access, tested recovery, supplier governance, evidence, and documented acceptance of residual risk.

9. Challenges and Limitations

Risk assessment is affected by incomplete inventories, changing threats, uncertain estimates, biased judgement, inconsistent scales, and pressure to produce reassuring results. Quantitative calculations may imply precision that the evidence cannot support. Qualitative scores may hide disagreement behind a single number.

Common failure patterns include counting vulnerabilities without considering assets, treating compliance checklists as complete risk analysis, assigning risks without owners, accepting risks indefinitely, and selecting controls before defining the threat scenario. Another failure is reviewing risk only annually when systems and threats change weekly.

Good practice includes recording rationale, separating facts from assumptions, using multiple evidence sources, involving business and technical stakeholders, testing controls, reviewing third parties, and setting event-driven reassessment triggers. Triggers include major system changes, new regulations, serious incidents, newly exploited vulnerabilities, supplier changes, and shifts in business criticality.

Best-Practice Decision Checklist

Before closing an assessment, confirm that:

• the scope and assumptions are explicit;
• important assets, owners, dependencies, and data flows are identified;
• threat events and vulnerabilities are described in specific terms;
• existing controls and their effectiveness are evidenced;
• likelihood and impact criteria are defined and consistently applied;
• inherent, current, and residual risk are distinguished;
• treatment decisions address legal and ethical duties as well as cost;
• every material risk has an accountable owner;
• actions have deadlines and evidence requirements; and
• review dates and change triggers are established.

Chapter Summary

Security risk assessment links organisational objectives to practical protection decisions. The process begins by defining scope and context, identifying assets and their owners, and understanding confidentiality, integrity, availability, privacy, resilience, and safety requirements. Threats describe potential causes of harm, vulnerabilities describe weaknesses, threat events describe what may happen, and impacts describe consequences.

Likelihood and impact can be assessed qualitatively using documented scales or estimated quantitatively where evidence supports monetary assumptions. Risk scores are decision aids rather than objective truths. A risk register provides traceability by recording scenarios, controls, owners, treatments, deadlines, assumptions, and review dates. Inherent risk describes exposure before controls, while residual risk remains after treatment.

The four principal treatment options are avoid, mitigate, transfer, and accept. Mitigation should be proportionate and layered; transfer does not remove accountability; and acceptance must be explicit, authorised, and reviewed. Legal obligations, privacy, ethics, governance, cloud responsibilities, and AI limitations must be integrated into the assessment. Effective risk management is continuous: it monitors change, tests controls, and revises decisions as evidence and circumstances evolve.

Key Terms

Asset: Anything of value that requires protection.

Asset owner: The person accountable for an asset’s protection and use.

Threat: A potential cause of harm.

Vulnerability: A weakness that may be exploited or triggered.

Threat event: An occurrence in which a threat acts against an asset.

Impact: The consequence of a threat event.

Risk: The possibility of harmful consequences arising from uncertainty.

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

Risk tolerance: The acceptable variation around a specific objective or exposure.

Inherent risk: Risk before considering controls.

Residual risk: Risk remaining after controls or treatment.

Control: A safeguard that modifies risk.

Risk register: A managed record of risks, decisions, owners, and actions.

Risk owner: The person accountable for deciding how a risk is managed.

Control owner: The person responsible for implementing or operating a control.

Risk treatment: The action selected to address risk.

Exposure factor: The estimated proportion of asset value lost in one incident.

Annualised loss expectancy: Estimated monetary loss expected per year under stated assumptions.

Multi-factor authentication: Authentication requiring two or more distinct factor types.

Residual-risk acceptance: An authorised decision to retain remaining exposure.

Review Questions

5 Short Answer Questions

1. Define an information security asset and give two examples.
2. Distinguish a threat from a vulnerability.
3. What is the purpose of a risk register?
4. Explain the difference between inherent risk and residual risk.
5. Name and briefly describe the four main risk treatment options.

5 Long Answer Questions

1. Explain a complete security risk assessment process from scoping through review.
2. Discuss how confidentiality, integrity, and availability requirements influence asset classification and control selection.
3. Compare qualitative risk scoring with basic quantitative loss estimation, including limitations of each approach.
4. Explain why risk ownership, control ownership, and documented acceptance are important to governance.
5. Discuss how legal, ethical, privacy, cloud, and AI considerations affect security risk decisions.

3 Analytical / Application Questions

1. A college discovers that a student-record system has excessive administrator privileges, incomplete logs, and no tested recovery procedure. Construct two specific risk statements, identify likely impacts, and recommend treatments.
2. An organisation assigns likelihood 4 and impact 5 to a remote-access risk. After multi-factor authentication is implemented, likelihood falls to 2 but impact remains 5. Explain what this means and identify further evidence needed before accepting the residual risk.
3. A company wants to transfer a customer-data risk entirely to a cloud provider. Analyse whether transfer alone removes the company’s responsibility, and recommend contractual and technical checks before approval.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a vulnerability from a threat?

A. A vulnerability is a potential cause of harm, while a threat is a weakness.

B. A vulnerability is a weakness, while a threat is a potential cause of harm.

C. A vulnerability is always an incident, while a threat is always a control.

D. A vulnerability measures impact, while a threat measures likelihood.

Correct Answer: B. A vulnerability is a weakness, while a threat is a potential cause of harm.

Question 2

In the qualitative model R = L × I, what do L and I represent?

A. Loss and insurance

B. Logging and integrity

C. Likelihood and impact

D. Legal duty and investment

Correct Answer: C. Likelihood and impact

Question 3

An asset is valued at £50,000 and the exposure factor is 0.20. What is the single loss expectancy?

A. £2,500

B. £10,000

C. £25,000

D. £250,000

Correct Answer: B. £10,000

Question 4

If the single loss expectancy is £10,000 and the annualised rate of occurrence is 0.3, what is the annualised loss expectancy?

A. £300

B. £3,000

C. £10,300

D. £30,000

Correct Answer: B. £3,000

Question 5

Which action is the clearest example of risk avoidance?

A. Adding multi-factor authentication to an existing service

B. Buying cyber insurance for a continuing activity

C. Discontinuing an unnecessary internet-facing service

D. Accepting a low residual risk in writing

Correct Answer: C. Discontinuing an unnecessary internet-facing service

Question 6

What is the principal purpose of assigning a risk owner?

A. To make one person technically operate every control

B. To establish accountability for deciding how the risk is managed

C. To eliminate the need for risk reviews

D. To transfer all legal responsibility to that person

Correct Answer: B. To establish accountability for deciding how the risk is managed

Question 7

Which statement about risk transfer is most accurate?

A. Transfer always eliminates the underlying risk.

B. Transfer removes the organisation’s legal and ethical responsibilities.

C. Transfer may share financial or operational consequences but does not necessarily remove accountability.

D. Transfer is identical to risk avoidance.

Correct Answer: C. Transfer may share financial or operational consequences but does not necessarily remove accountability.

Question 8

A risk scored with likelihood 4 and impact 5 on a 1–5 matrix has a score of:

A. 9

B. 16

C. 20

D. 25

Correct Answer: C. 20

Question 9

Why should a written backup policy be tested?

A. Because policy documents automatically create recoverable backups.

B. Because testing provides evidence that restoration can actually work.

C. Because testing changes an availability impact into a confidentiality impact.

D. Because tested backups eliminate all ransomware risk.

Correct Answer: B. Because testing provides evidence that restoration can actually work.

Question 10

Which practice best supports responsible use of AI in risk assessment?

A. Allowing AI output to replace the risk owner’s judgement without review

B. Entering all sensitive incident data into any public AI service

C. Validating AI-supported analysis, documenting assumptions, and retaining human accountability

D. Prioritising every vulnerability solely by an automated score

Correct Answer: C. Validating AI-supported analysis, documenting assumptions, and retaining human accountability