Cyber Laws, Risk Management & Security Governance

Chapter 7
Information-Security Risk Foundations

Diploma in Cybersecurity
Cyber Laws, Risk Management & Security Governance   •   Diploma

Information-Security Risk Foundations

Introduction

Information-security risk management is the disciplined process of understanding what an organisation must protect, how those assets may be harmed, what safeguards are available, and which risks require treatment. It is not limited to technical vulnerabilities or cyberattacks. Risk may arise from human error, weak governance, supplier failure, system malfunction, legal non-compliance, physical disruption, or deliberate criminal activity.

A sound risk-management process enables an organisation to make defensible decisions about security. It helps leaders determine where to invest, how much disruption is acceptable, who is accountable, and whether a risk should be reduced, transferred, avoided, or accepted. In this sense, risk management connects cybersecurity operations with organisational objectives and governance.

This chapter establishes the foundations needed to perform a basic information-security risk assessment and maintain a useful risk register. It introduces organisational context, risk appetite, risk criteria, assets, threats, vulnerabilities, controls, likelihood, impact, inherent risk, residual risk, risk ownership, risk statements, and treatment decisions.

Learning Objectives

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

  1. Explain the relationship between organisational objectives, information assets and security risk.
  2. Distinguish threats, vulnerabilities, events, impacts and controls.
  3. Describe risk appetite, risk tolerance and risk criteria.
  4. Construct clear and useful risk statements.
  5. Differentiate inherent risk from residual risk.
  6. Estimate likelihood and impact using qualitative and simple quantitative methods.
  7. Assign appropriate risk owners and maintain a risk register.
  8. Apply the concepts to a realistic organisational case.

1. Risk in an Organisational Context

Risk is commonly understood as the effect of uncertainty on objectives. The effect may be positive or negative, although information-security risk normally focuses on harmful consequences. Objectives may include delivering services, protecting personal information, maintaining public trust, complying with law, achieving financial targets, or ensuring safety.

Security risk exists when uncertainty could affect the confidentiality, integrity or availability of information or information-processing systems. These three properties are often called the CIA triad:

  • Confidentiality: information is accessible only to authorised people, processes or systems.
  • Integrity: information remains accurate, complete and protected from unauthorised alteration.
  • Availability: information and services are accessible when required by authorised users.

Other security properties may also be important. Authenticity concerns whether an identity, message or system is genuine. Accountability enables actions to be attributed to responsible subjects. Privacy concerns the appropriate collection, use, disclosure and retention of personal information.

Risk cannot be assessed properly in isolation from the organisation. A brief outage may be tolerable for an internal document repository but unacceptable for an emergency-response system. A disclosure of one type of information may be minor in one context and legally or socially severe in another. Consequently, risk assessment begins by establishing context.

Organisational context

Context describes the circumstances in which risk decisions are made. It normally includes:

  • organisational mission, strategy and critical services;
  • legal, regulatory and contractual obligations;
  • internal structures, policies and decision rights;
  • technology architecture and information flows;
  • dependence on suppliers, cloud providers and partners;
  • relevant stakeholders and their expectations;
  • financial, operational and reputational constraints;
  • threat environment and geographic considerations.

For example, a healthcare provider may identify patient safety, clinical continuity and privacy law as major contextual factors. A small online retailer may prioritise payment-card protection, availability during peak sales, and customer trust. The same technical weakness can therefore produce different risk ratings in different organisations.

2. Risk Appetite, Tolerance and Criteria

Risk appetite

Risk appetite is the amount and type of risk an organisation is willing to pursue, retain or accept in order to achieve its objectives. It is a governance decision, normally approved by senior management or the governing body.

Risk appetite should be expressed in practical terms. An organisation might have:

  • very low appetite for unauthorised disclosure of health information;
  • moderate appetite for temporary interruption of non-critical internal services;
  • limited appetite for dependence on a single supplier;
  • no appetite for knowingly violating a legal requirement.

Risk appetite is not the same as a desire to experience risk. It describes the boundaries within which decision-making may occur.

Risk tolerance

Risk tolerance is the acceptable variation around an objective or risk boundary. For example, an organisation may set a tolerance of no more than four hours of service interruption for a critical application, or no more than one reportable privacy incident in a defined period. Tolerance is usually more specific and measurable than appetite.

Risk criteria

Risk criteria are the terms used to judge the significance of risk. They may define rating scales, thresholds and escalation rules. Criteria commonly consider:

  • financial loss;
  • service downtime;
  • number and sensitivity of affected records;
  • safety or health consequences;
  • legal and regulatory exposure;
  • reputational damage;
  • strategic consequences;
  • recovery complexity.

Criteria should be approved before assessments are performed. Otherwise, assessors may unconsciously change standards from one risk to another.

Example of a five-level scale

RatingLikelihood descriptionImpact description
1Rare; not expected in ordinary circumstancesInsignificant; little operational effect
2Unlikely; could occur occasionallyMinor; manageable local disruption
3Possible; credible and plausibleModerate; material operational or compliance effect
4Likely; expected in many circumstancesMajor; serious service, financial or legal effect
5Almost certain; frequent or imminentSevere; critical, extensive or potentially catastrophic effect

These labels are not universal. Each organisation should define them using evidence and context. A five-level scale is useful for communication, but it is not a substitute for judgement.

3. The Elements of Information-Security Risk

A risk assessment becomes clearer when its components are separated.

Assets

An asset is something that has value to the organisation and therefore requires protection. Assets include more than hardware. Examples are:

  • customer and employee information;
  • financial records and intellectual property;
  • business applications and databases;
  • networks, endpoints and cloud resources;
  • authentication credentials and cryptographic keys;
  • business processes and critical services;
  • facilities, equipment and staff knowledge;
  • organisational reputation.

An asset inventory should identify owners, locations, dependencies, classification and security requirements. It should also identify information flows, because data may be exposed while being collected, processed, transmitted, backed up or disposed of.

Threats and threat actors

A threat is a potential cause of an unwanted incident. A threat actor is the person, group, process or natural event capable of creating that threat. Threat actors may include criminals, malicious insiders, competitors, hacktivists, states, careless employees, suppliers or automated malware.

Threats can be deliberate, accidental or environmental. Examples include phishing, ransomware, incorrect configuration, power failure, fire, flood, equipment failure and unauthorised disclosure by an employee.

Vulnerabilities

A vulnerability is a weakness that can be exploited or otherwise contribute to an unwanted event. Examples include unpatched software, excessive privileges, poor backup design, weak passwords, inadequate monitoring, unclear procedures and insufficient staff training.

A vulnerability alone is not necessarily a realised risk. It becomes significant when a relevant threat can exploit it and the resulting impact matters to the organisation.

Events and consequences

A risk event is an occurrence that may cause harm. For example, an attacker may use stolen credentials to access a cloud storage account. The consequences may include disclosure of personal information, regulatory investigation, notification costs and loss of customer confidence.

A useful causal chain is:

Threat source → vulnerability or exposure → event → consequence affecting an objective

This chain helps avoid vague statements such as “cyberattack risk.” It identifies what could happen, why it could happen and what the organisation would experience.

Controls

A control is a measure that modifies risk. Controls may be:

  • preventive, such as access restrictions and secure configuration;
  • detective, such as logging, monitoring and alerting;
  • corrective, such as malware removal and system restoration;
  • deterrent, such as disciplinary rules and visible security controls;
  • directive, such as policies, standards and training;
  • compensating, where an alternative measure reduces risk when the preferred control is unavailable.

Controls may be administrative, technical, physical or procedural. A firewall is not automatically an effective control: its effectiveness depends on design, configuration, monitoring, maintenance and coverage.

4. Risk Statements

A risk statement describes a possible event, its cause and its consequence. A practical structure is:

Because of [threat or cause] exploiting [vulnerability or condition], [event] may occur, resulting in [impact on objective].

Example:

Because external remote-access services are protected by weak authentication, a criminal may use stolen credentials to access the finance system, resulting in fraudulent payments and disclosure of payroll information.

This is stronger than “weak passwords” because it expresses a complete risk scenario. It also supports the selection of controls.

A good risk statement should be:

  • specific enough to support action;
  • written in terms of organisational objectives;
  • understandable to technical and non-technical decision-makers;
  • free from unexplained jargon;
  • neither so broad that it covers many unrelated scenarios nor so narrow that it becomes unmanageable.

5. Likelihood, Impact and Risk Evaluation

Likelihood expresses how probable or credible a risk event is within a defined period. Impact describes the magnitude of harm if the event occurs. Both require evidence and assumptions.

Evidence may include incident history, vulnerability data, threat intelligence, audit findings, control-test results, business-impact analysis, supplier information and expert judgement. Assessors should record the basis for ratings rather than presenting unsupported numbers as facts.

Qualitative risk matrix

Many organisations use a matrix combining likelihood and impact. A simple model assigns each a value from 1 to 5 and calculates a score:

R = L × I

where R is the risk score, L is the likelihood rating and I is the impact rating. The score has no universal unit and should be used only under the organisation’s approved criteria. It is an ordinal decision aid, not a precise probability of loss.

For example, if likelihood is rated 4 and impact is rated 5:

R = 4 × 5 = 20

If the organisation defines scores from 15 to 25 as high, the risk is high under that specific methodology. Another organisation may use different thresholds.

A matrix should not obscure important distinctions. Two risks may both score 12, while one threatens personal safety and the other causes a short internal outage. Escalation rules should therefore allow exceptionally severe impacts to receive attention even when the calculated score is moderate.

Quantitative estimation

Where reliable data exists, annualised loss expectancy can support financial analysis:

ALE = SLE × ARO

where ALE is annualised loss expectancy, SLE is single-loss expectancy in currency units, and ARO is the estimated annual rate of occurrence. If a single incident is estimated to cost £40,000 and is expected to occur 0.25 times per year, then:

ALE = £40,000 × 0.25 = £10,000 per year

This estimate assumes that the loss amount and occurrence rate are meaningful approximations and that the events can be represented adequately by an annual average. It does not predict exactly what will happen in a particular year. It should not be used when data is too weak to support the estimates.

6. Inherent and Residual Risk

Inherent risk is the level of risk before considering existing controls. It represents the exposure created by the activity or environment as it currently exists conceptually without those safeguards.

Residual risk is the risk remaining after controls are considered. A control may reduce likelihood, impact, or both. For example, tested backups may not prevent ransomware, but they can reduce recovery time and data loss.

A useful assessment sequence is:

  1. identify the asset and objective;
  2. describe the threat scenario;
  3. assess inherent likelihood and impact;
  4. identify existing controls;
  5. evaluate control design and operating effectiveness;
  6. reassess likelihood and impact;
  7. record residual risk;
  8. decide whether further treatment is required.

Controls should not be treated as automatically effective. The assessor should ask whether the control is implemented, consistently operated, monitored, tested and appropriate to the scenario.

7. Risk Treatment and Ownership

Risk treatment is the process of selecting and implementing a response. Common responses are:

  • Avoid: stop the activity or change the design so the risk no longer arises.
  • Reduce or modify: implement controls to lower likelihood or impact.
  • Share or transfer: allocate part of the financial or operational consequence to another party, for example through insurance or a contract. Accountability for compliance and oversight is not automatically transferred.
  • Retain or accept: consciously retain the risk within approved appetite and tolerance.

Risk acceptance should be explicit, informed and time-bound where appropriate. It should identify the decision-maker, the risk being accepted, the rationale, the review date and any conditions.

Risk ownership

A risk owner is the person accountable for ensuring that a risk is managed. The risk owner must have sufficient authority, resources and knowledge to make decisions. This is not always the same as:

  • the asset owner, who is responsible for an asset;
  • the control owner, who operates a particular control;
  • the system administrator, who performs technical tasks;
  • the risk assessor, who analyses and documents the risk.

For example, the finance director may own the risk of fraudulent payments, while the security team owns implementation of multi-factor authentication and the infrastructure team operates endpoint controls.

8. The Risk Register

A risk register is a controlled record of identified risks, assessments, owners, treatments and status. It is both an operational tool and a governance record.

A practical risk-register entry may contain:

FieldPurpose
Risk IDProvides a unique reference
Date and statusShows currency and lifecycle state
Asset or serviceIdentifies what is at stake
ObjectiveStates what must be protected or achieved
Risk statementDescribes cause, event and consequence
Threat and vulnerabilityExplains the scenario
Existing controlsRecords current safeguards
Inherent ratingShows exposure before controls
Residual ratingShows exposure after controls
Risk ownerAssigns accountability
Treatment decisionRecords avoid, reduce, share or accept decision
Action and due dateConverts treatment into work
Evidence and review dateSupports assurance and reassessment

The register should not become a static spreadsheet that is updated only before an audit. It should be reviewed when there are significant changes, such as a new system, major supplier, security incident, regulatory change, organisational restructuring or change in threat conditions.

Risk registers also have limitations. They can create false precision, encourage a focus on scores rather than scenarios, and become overloaded with low-value entries. A concise register linked to business decisions is more useful than a large catalogue of unprioritised weaknesses.

9. Applied Case: Northbridge College Student Portal

The following is an illustrative fictional case.

Background

Northbridge College operates an online student portal used for enrolment, examination results, fee payments and access to personal records. The portal is hosted by a cloud service provider. Students and staff access it through the public internet.

Problem

An internal review finds that administrator accounts use passwords but not multi-factor authentication. Several accounts have broad privileges, and the provider’s security logs are retained for only seven days. The portal contains names, addresses, identification numbers, grades and payment-related information.

Analysis

The principal asset is the student information service and its associated records. Relevant objectives include confidentiality of personal information, integrity of grades and availability during enrolment and examinations.

A suitable risk statement is:

Because privileged portal accounts lack multi-factor authentication and have excessive permissions, an attacker using stolen credentials may alter grades or extract student records, resulting in privacy breaches, loss of academic integrity and regulatory consequences.

The threat is credential compromise by an external attacker. Vulnerabilities include weak authentication, excessive privilege and limited monitoring. Existing controls may include passwords, provider access controls, backups and general security policies, but their effectiveness is incomplete.

Suppose the college rates inherent likelihood as 4 and inherent impact as 5. Under its approved matrix, the score is 20, classified as high. After introducing multi-factor authentication, privileged-access management, monthly access reviews, longer log retention and alerting for unusual exports, likelihood may be reassessed as 2 while impact remains 5. The residual score is therefore:

R = 2 × 5 = 10

The residual rating may fall into the college’s medium category, but the impact remains severe. The college should therefore define continued monitoring and escalation conditions rather than assuming that the score means the risk is unimportant.

Approach and solution

The college assigns the risk to the director responsible for digital services, because that person can approve funding and operational changes. The information-security manager becomes the control coordinator. The college requires the cloud provider to support multi-factor authentication, privileged access separation, security logging and incident notification within the contractual period.

Treatment actions include:

  1. enabling multi-factor authentication for all privileged users;
  2. removing unnecessary administrative permissions;
  3. reviewing access monthly and after staff changes;
  4. retaining logs for a period consistent with investigation and legal needs;
  5. monitoring unusual downloads and grade changes;
  6. testing restoration and incident-response procedures;
  7. reviewing the provider’s independent assurance reports.

Outcome

The risk is reduced but not eliminated. The college documents residual risk, assigns review dates and defines indicators such as failed authentication spikes, unusual exports, overdue access reviews and provider control exceptions. Senior management accepts the remaining risk subject to these conditions.

Learning points

The case demonstrates that:

  • risk must be linked to services and objectives, not merely vulnerabilities;
  • a control can reduce likelihood without eliminating impact;
  • cloud outsourcing does not remove the customer’s governance responsibilities;
  • risk ownership belongs with someone able to make decisions and commit resources;
  • a risk register should record assumptions, actions, evidence and review dates.

10. Governance, Legal and Ethical Considerations

Risk decisions affect people, not just systems. Privacy principles generally require organisations to protect personal information through appropriate technical and organisational measures. Applicable duties depend on jurisdiction and sector, but may include data-protection law, breach notification obligations, contractual requirements, records-management rules and sector-specific regulation.

Organisations should avoid collecting excessive information merely because storage is inexpensive. They should consider proportionality, purpose limitation, retention, access rights and secure disposal. Risk assessments involving personal data should recognise harms such as discrimination, identity theft, distress and loss of autonomy, not only financial cost.

Ethically, security controls should be effective without being unnecessarily intrusive or discriminatory. Monitoring should have a legitimate purpose, clear governance and appropriate access restrictions. Automated risk scoring should be explainable enough for responsible review, especially when decisions affect employees, customers or access to services.

Senior leaders have a duty to ensure that risk acceptance is informed. Concealing known risks, manipulating ratings to avoid escalation, or treating compliance as proof of security are failures of governance. Compliance can establish a minimum obligation, but effective security requires continuous assessment and improvement.

11. Contemporary Practice and Limitations

Modern organisations face increasingly distributed environments: cloud services, remote work, mobile devices, software supply chains, application programming interfaces and connected operational technology. Asset boundaries are therefore less obvious than in traditional data centres. Risk assessments must consider dependencies and concentration risk, such as reliance on a single cloud provider or identity service.

Artificial intelligence can assist with anomaly detection, vulnerability prioritisation and analysis of large evidence sets. However, AI-generated assessments may contain inaccurate assumptions, biased data or unexplained conclusions. Human review, data protection, model governance and clear accountability remain necessary. AI is a tool for risk analysis, not a replacement for ownership or judgement.

Important limitations include:

  • likelihood estimates may be uncertain because incidents are under-reported;
  • impact may include intangible consequences that are difficult to price;
  • risk scores can hide differences between scenarios;
  • controls may fail together because of common dependencies;
  • threat conditions and business objectives change over time;
  • historical data may not represent emerging attacks.

Good practice is therefore iterative. Organisations should combine structured methods with professional judgement, validate assumptions, test controls, learn from incidents and reassess after significant change.

Best-Practice Checklist

Before finalising an information-security risk assessment, ask:

  1. Is the organisational objective clearly stated?
  2. Is the asset or service identified, including important dependencies?
  3. Does the risk statement describe a cause, event and consequence?
  4. Are threats and vulnerabilities supported by evidence?
  5. Are likelihood and impact defined using approved criteria?
  6. Are inherent and residual risk distinguished?
  7. Have control design and operating effectiveness been considered?
  8. Is the risk owner authorised and accountable?
  9. Is the treatment decision explicit and within appetite?
  10. Are actions, due dates, evidence and review triggers recorded?
  11. Have legal, privacy, ethical and third-party issues been considered?
  12. Can a non-technical decision-maker understand the entry?

Chapter Summary

Information-security risk management begins with organisational context. Assets, services and objectives determine what matters; threats and vulnerabilities explain how harm may occur; events connect causes to consequences; and controls modify likelihood or impact. Risk appetite expresses the amount and type of risk an organisation is prepared to retain, while tolerance and criteria provide practical boundaries for decisions.

Clear risk statements are built around cause, event and consequence. Likelihood and impact may be assessed qualitatively or, where evidence permits, quantitatively. A simple matrix score such as R = L × I supports comparison but does not represent precise probability or loss. Inherent risk describes exposure before controls, whereas residual risk is the exposure remaining after controls.

Effective governance requires named risk owners, informed treatment decisions and a living risk register. Risk may be avoided, reduced, shared or accepted. Legal, privacy and ethical considerations must be integrated into assessment rather than added after technical analysis. Because systems, threats and organisational objectives change, risk management is a continuing cycle of review, treatment, assurance and learning.

Key Terms

Asset: Anything valuable to an organisation that requires protection.

Availability: The property that information and services are accessible when required.

Confidentiality: The property that information is accessible only to authorised parties.

Control: A measure that modifies risk.

Impact: The consequence or magnitude of harm resulting from a risk event.

Inherent risk: Risk considered before existing controls are taken into account.

Integrity: The property that information remains accurate, complete and protected from unauthorised alteration.

Likelihood: The probability or credibility that a risk event will occur within a defined context or period.

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

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

Risk assessment: The process of identifying, analysing and evaluating risk.

Risk criteria: Terms and thresholds used to judge the significance of risk.

Risk event: An occurrence that may cause harm to an objective.

Risk owner: The person accountable for ensuring that a risk is managed.

Risk register: A controlled record of risks, ratings, owners, treatments and status.

Risk statement: A structured description of a cause, event and consequence.

Risk tolerance: The acceptable variation around an objective or risk boundary.

Threat: A potential cause of an unwanted incident.

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

Review Questions

Short Answer Questions

  1. What are the three properties of the CIA triad?
  2. Distinguish risk appetite from risk tolerance.
  3. What is the difference between a threat and a vulnerability?
  4. Define residual risk.
  5. State two fields that should appear in a risk register.

Long Answer Questions

  1. Explain how organisational context influences information-security risk assessment.
  2. Describe the relationship between assets, threats, vulnerabilities, events, impacts and controls.
  3. Explain the difference between inherent risk and residual risk, using an example.
  4. Discuss the responsibilities of a risk owner, asset owner and control owner.
  5. Evaluate the benefits and limitations of using a five-by-five risk matrix.

Analytical / Application Questions

  1. A university’s learning platform has no tested backups. Write a complete risk statement and identify the likely asset, threat, vulnerability, impact and treatment options.
  2. A company rates a risk with likelihood 3 and impact 4. Using R = L × I, calculate the score, then explain why the score alone is insufficient for a management decision.
  3. A cloud provider manages an organisation’s customer database. Identify three risks created by this dependency and explain how ownership and contractual controls should be addressed.

Multiple Choice Questions with Answers

Question 1

Which statement best describes risk appetite?

A. The amount and type of risk an organisation is willing to pursue, retain or accept

B. The number of vulnerabilities found during a technical scan

C. The time required to restore a failed system

D. The probability that a particular attack will occur

Correct Answer: A. The amount and type of risk an organisation is willing to pursue, retain or accept

Question 2

Which sequence most accurately represents a typical risk scenario?

A. Control → asset → policy → budget

B. Threat source → vulnerability or exposure → event → consequence

C. Impact → password → threat actor → audit

D. Risk owner → firewall → asset → regulation

Correct Answer: B. Threat source → vulnerability or exposure → event → consequence

Question 3

A risk has a likelihood rating of 4 and an impact rating of 5. Using R = L × I, what is its score?

A. 9

B. 15

C. 20

D. 25

Correct Answer: C. 20

Question 4

What is residual risk?

A. Risk before any safeguards are considered

B. Risk remaining after controls are considered

C. Risk transferred entirely to an insurer

D. Risk that has no possible consequence

Correct Answer: B. Risk remaining after controls are considered

Question 5

Which person is normally the risk owner?

A. The person with authority and accountability to ensure the risk is managed

B. Any employee who reports a vulnerability

C. Only the external penetration tester

D. The person who created the original software

Correct Answer: A. The person with authority and accountability to ensure the risk is managed

Question 6

Which option is an example of a detective control?

A. Security monitoring that generates an alert for unusual data exports

B. A policy requiring strong passwords

C. A backup used after data loss

D. A locked server-room door

Correct Answer: A. Security monitoring that generates an alert for unusual data exports

Question 7

Why should a risk statement include both a cause and a consequence?

A. To make the statement longer for audit purposes

B. To connect the scenario to an actionable weakness and an organisational objective

C. To guarantee that the risk will occur

D. To replace the need for a risk owner

Correct Answer: B. To connect the scenario to an actionable weakness and an organisational objective

Question 8

An annual loss estimate uses a single-loss expectancy of £40,000 and an annual rate of occurrence of 0.25. What is the annualised loss expectancy?

A. £1,000

B. £10,000

C. £40,250

D. £160,000

Correct Answer: B. £10,000

Question 9

Which is a limitation of a numerical risk score?

A. It can never be used to compare risks

B. It always represents an exact probability of financial loss

C. It may hide important differences between risks with the same score

D. It eliminates the need for professional judgement

Correct Answer: C. It may hide important differences between risks with the same score

Question 10

Which treatment response involves stopping an activity or redesigning it so the risk no longer arises?

A. Acceptance

B. Transfer

C. Reduction

D. Avoidance

Correct Answer: D. Avoidance

Cyber Laws, Risk Management & Security Governance
Chapter 7 of 15