Lesson 6.3: Risk Management Frameworks

00 Introduction

Lesson 6.1 examined cybersecurity governance — the structures and accountabilities through which security is directed. Lesson 6.2 examined policy — the instrument through which governance intent becomes binding requirement. This lesson examines the discipline that connects them: risk management.

Risk management is how an enterprise determines what matters, what could go wrong, how bad it would be, what should be done about it, and whether the actions taken are working. It is the mechanism through which the finite resources available for security are allocated — not by preference, not by loudest voice, and not by whatever was done last year, but by an assessment of what the enterprise stands to lose and what it can reasonably do to reduce that loss.

Risk management is also how the enterprise connects its security effort to its business objectives. A security programme that manages risk without reference to the business produces controls that protect the wrong things; a business that pursues objectives without understanding the risk it is taking produces surprises. Risk management is the translation layer between what the business is trying to achieve and what could prevent it from achieving it.

This lesson examines risk management frameworks in detail. It establishes why risk management matters and what happens in its absence. It revisits the fundamentals of risk — the concepts of asset, threat, vulnerability, likelihood, impact, and risk itself — building on the material in Unit 3. It examines the principal frameworks: the NIST Risk Management Framework, ISO 31000, ISO/IEC 27005, FAIR, and COSO ERM — and what each provides. It examines the risk management process in detail — identification, assessment, analysis, evaluation, treatment, monitoring, and reporting. It examines risk identification techniques, risk assessment methods including qualitative, semi-quantitative, and quantitative approaches, risk treatment options, and risk monitoring. It examines cyber risk quantification in detail — the discipline of expressing cyber risk in financial terms. It examines risk registers and risk ownership. And it closes with the pitfalls that recur across risk management programmes.

The material here builds directly on Unit 3 (risk fundamentals, threat modelling, vulnerability assessment) and on Lessons 6.1 and 6.2 — risk appetite is the governance instrument that risk management applies, and policy is frequently the output of risk treatment decisions. It prepares for Lesson 6.4 (compliance — the external requirements that risk management must satisfy), Lesson 6.6 (auditing — how risk management is independently assessed), and Lessons 6.7–6.9 (incident response, continuity, and resilience — all of which are risk treatments).

How to read this lesson

Sections 1–2 establish the framing and the fundamentals. Section 3 examines the frameworks. Sections 4–8 examine the process in detail. Section 9 examines quantification. Section 10 examines registers and ownership. Section 11 addresses the pitfalls. If you are short on time, read Sections 3, 4, 6, and 9 carefully — the frameworks, the process, risk assessment methods, and quantification are the most consequential material for enterprise practice and for the assessment.

01 Learning objectives

By the end of this lesson you should be able to:

Lesson objectives

Explain why risk management matters and what characterises organisations where it is absent or ineffective.
Define the fundamental risk concepts — asset, threat, vulnerability, likelihood, impact, inherent risk, residual risk, and risk appetite.
Describe the principal risk management frameworks — NIST RMF, ISO 31000, ISO/IEC 27005, FAIR, and COSO ERM — and what each provides.
Apply the risk management process — identification, assessment, analysis, evaluation, treatment, monitoring, and reporting.
Evaluate risk identification techniques — asset-based, threat-based, scenario-based, and control-based approaches.
Compare qualitative, semi-quantitative, and quantitative risk assessment methods and their appropriate uses.
Apply risk treatment options — mitigate, transfer, accept, and avoid — and select appropriate treatments.
Design risk monitoring and reporting — key risk indicators, risk dashboards, and board reporting.
Evaluate cyber risk quantification approaches — FAIR, factor analysis, and Monte Carlo simulation.
Design a risk register and risk ownership model appropriate to an enterprise.
Identify common enterprise pitfalls in risk management programmes.

These objectives contribute to Unit 6 outcomes U6.1 (governance frameworks) and U6.3 (risk management), and to Module 3 outcomes M3.2, M3.3, and M3.5. See the Unit 6 learning outcomes page for the full mapping.

02 Why risk management matters

Risk management matters because security resources are finite and risk is not. Every enterprise has more exposure than it can eliminate, more vulnerabilities than it can patch, and more potential controls than it can fund. Risk management is the discipline through which those finite resources are directed toward the exposures that matter most — and through which the enterprise understands what it is choosing to live with.

It directs finite resources

An enterprise cannot secure everything to the same standard — the cost would exceed the value of the business.
Risk management identifies where the greatest exposure lies, so that investment is directed there rather than distributed evenly or allocated by preference.
It provides the basis on which the enterprise can say "we are doing enough here, and not enough there" — and explain why.

It connects security to business objectives

Security exists to enable the business to achieve its objectives — not as an end in itself.
Risk management frames security in terms of what the business stands to lose if a risk materialises — revenue, customers, regulatory standing, safety, reputation.
It permits the business to make informed choices about the risk it is taking, rather than discovering it after the fact.

It provides the basis for accountability

Risk management assigns each risk a named owner, who is accountable for its treatment or its acceptance.
It documents what was known, what was decided, and by whom — providing the basis for accountability when things go wrong.
It makes the question "who decided to accept this risk?" answerable — a question regulators and courts increasingly ask.

It informs governance

The board's principal instrument of control over cyber risk is the risk appetite it sets — which only has meaning if risk is being measured against it.
Risk management provides the reporting that permits the board to understand the enterprise's position, and to challenge it.
Without risk management, governance is conducted in the absence of information about what the enterprise is actually exposed to.

It is required by regulation and standard

ISO/IEC 27001, NIST CSF, NIS2, financial sector regulation, and sector-specific regimes all require a documented, operating risk management process.
Regulators increasingly expect evidence that risk has been identified, assessed, and treated — not merely that controls exist.
Risk management is frequently the framework through which compliance obligations are operationalised.

It supports defensible decision-making

Where an incident occurs, the enterprise will be asked what it knew, what it decided, and why.
A documented risk management process demonstrates that decisions were made deliberately, on the basis of assessment, with accountability.
Its absence — or a process that produces documentation but no decisions — provides no such defence.

What risk management failure looks like

Risk management failures are recognisable, and the patterns repeat:

No risk management process exists. Security decisions are made on the basis of technical preference, vendor recommendation, or the most recent incident — with no systematic assessment of what the enterprise is exposed to.
The risk register is a document, not a process. Risks are entered once and never reviewed; the register grows and is never used to make a decision.
Every risk is rated "high." Without a consistent assessment method, everything is a priority — which means nothing is.
Risks are identified but never treated or accepted. The register lists exposures that no one has decided what to do about.
Risks have no owner. Each risk is assigned to a committee, a department, or "the business" — so no individual is accountable.
Risk assessment is a compliance exercise. The process is performed annually to satisfy an audit, and produces documentation that has no influence on decisions.
Risk is assessed only for new systems. Existing systems are assumed to be acceptable because they have not yet caused a problem.
Risk reporting is disconnected from decision-making. The board receives risk reports that do not inform any decision, and makes decisions that are not informed by the risk reports.
Risk appetite is not applied. The appetite statement exists but is never used to determine whether a risk requires treatment or escalation.
Risk management is performed by the security team alone. Business units and system owners are not involved, so the assessment reflects technical exposure rather than business consequence.

The defining characteristic

The defining characteristic of an organisation without effective risk management is that no one can explain why the security budget is allocated as it is. In organisations with risk management, the allocation reflects an assessment of where the greatest exposure lies, and the reasoning can be stated. In organisations without it, the allocation reflects history, preference, and the last incident — and no one can say whether it is right or wrong.

03 Risk fundamentals

Risk management rests on a set of concepts that are used precisely in the discipline and loosely in general conversation. Precision matters, because imprecise concepts produce imprecise assessment.

The core concepts

Asset: Anything of value to the enterprise that could be affected by a risk — information, systems, infrastructure, people, processes, reputation, and the enterprise's ability to operate.
Threat: Anything that could cause harm to an asset — an adversary, an accident, a natural event, or an error. Threats have intent and capability (in the case of adversaries) or likelihood (in the case of events).
Vulnerability: A weakness that a threat could exploit to cause harm — a technical flaw, a configuration error, a process gap, or a human susceptibility.
Threat event: The occurrence of a threat acting against a vulnerability — the point at which potential harm becomes actual harm.
Likelihood: The probability that a threat event will occur — expressed as a frequency (events per year), a probability (0–1), or a qualitative rating (low, medium, high).
Impact: The consequence if a threat event occurs — expressed in financial terms, operational terms, regulatory terms, or qualitative ratings.
Risk: The combination of the likelihood of a threat event and the impact if it occurs. Risk is a function of both — high likelihood with low impact and low likelihood with high impact both produce risk, but of different characters requiring different responses.
Inherent risk: The risk that exists before any controls are applied — the exposure the enterprise would carry if it did nothing.
Residual risk: The risk that remains after controls have been applied — the exposure the enterprise actually carries.
Control: A measure that modifies risk — reducing likelihood, reducing impact, or both. Controls may be preventive, detective, or corrective.
Risk appetite: The amount and type of risk the enterprise is willing to pursue or retain — set by the board, as examined in Lesson 6.1.
Risk tolerance: The acceptable variation in outcome relative to a specific objective — a measurable expression of appetite.
Risk treatment: The action taken in response to a risk — mitigate, transfer, accept, or avoid.
Risk owner: The named individual accountable for a risk — for its treatment, its monitoring, and its acceptance where applicable.

The risk equation

The fundamental relationship in risk management is:

Risk = Likelihood × Impact

The equation is deliberately simple, and its simplicity is its strength. It states that risk has two dimensions, and that both must be considered. A vulnerability that is trivially exploitable but affects a non-critical system produces low risk; a vulnerability that is difficult to exploit but would be catastrophic produces high risk. Managing only likelihood (patching everything) or only impact (protecting the crown jewels) produces an incomplete picture.

More complete formulations expand the likelihood term:

Risk = Threat × Vulnerability × Impact

This formulation distinguishes between the threat (does an adversary exist, and are they capable?) and the vulnerability (is there a weakness they could exploit?). The distinction matters for treatment: a risk may be reduced by removing the vulnerability (patching, hardening) or by reducing the threat (blocking the adversary, removing the attack path).

Inherent and residual risk

The distinction between inherent and residual risk is one of the most practically useful in risk management:

Inherent risk is the exposure before controls — what the enterprise would face if it did nothing.
Residual risk is the exposure after controls — what the enterprise actually faces.
The gap between them is the value of the controls. A control that does not reduce risk from inherent to residual is not a control — it is activity.
Residual risk is what is compared against appetite. The enterprise accepts residual risk, not inherent risk — because controls have already been applied.
Residual risk is what remains on the register. The register records what the enterprise is carrying, not what it would be carrying without any controls.

Qualitative, semi-quantitative, and quantitative risk

Risk can be expressed at different levels of precision:

Approaches to expressing risk
Approach	Expression	Strengths	Limitations
Qualitative	Descriptive ratings — Low, Medium, High, Critical	Quick; requires no numerical data; comprehensible to non-specialists; suitable for broad assessment.	Subjective; ratings are not comparable across assessors; cannot be aggregated; cannot support cost-benefit analysis.
Semi-quantitative	Numerical scales — 1–5 for likelihood and impact, multiplied for a risk score	More consistent than purely qualitative; permits ranking; produces a risk matrix that can be communicated.	Numbers imply precision that does not exist; scales are frequently ordinal but treated as cardinal; aggregation is mathematically questionable.
Quantitative	Financial values — annualised loss expectancy, probability distributions, monetary ranges	Permits comparison with other business risks; supports cost-benefit analysis of controls; enables aggregation and portfolio view; defensible in financial terms.	Requires data that is frequently unavailable; complex; model-dependent; results may convey false precision.

In practice, most enterprises use a combination — qualitative or semi-quantitative assessment for the broad risk register, and quantitative analysis for the most significant risks or for investment decisions where the financial case must be made.

The most useful framing

The most useful framing for risk fundamentals is that risk is a statement about the future, not a fact about the present. It is a prediction — informed by evidence, but a prediction nonetheless. This has two consequences. First, precision should be proportionate to the quality of the underlying data: presenting a residual risk of "$4,237,891" based on a qualitative assessment is false precision. Second, the value of risk management is not in the accuracy of the prediction but in the discipline of thinking it through — identifying what could happen, considering how likely it is, assessing what it would cost, and deciding what to do about it.

04 Risk management frameworks

Several published frameworks define how risk management should be structured. They differ in scope, in the disciplines they address, and in the level of detail they provide — but they share a common structure around identification, assessment, treatment, and monitoring.

The principal frameworks

Principal risk management frameworks
Framework	Scope and character	Principal use
ISO 31000	General risk management — principles, framework, and process. Sector-agnostic and applicable to any type of risk. Deliberately does not prescribe specific methods or scales.	The reference for establishing a risk management framework; used as the basis for sector-specific applications.
ISO/IEC 27005	Information security risk management — applying ISO 31000 to information security. Provides detailed guidance on identification, analysis, evaluation, treatment, and monitoring in a security context.	The standard reference for information security risk management; frequently used alongside ISO/IEC 27001.
NIST RMF (SP 800-37)	The Risk Management Framework — a seven-step process for managing security and privacy risk across the system lifecycle, closely linked to the NIST SP 800-53 control catalogue.	Widely used in US federal and defence contexts; the reference framework for control-based risk management.
NIST SP 800-30	Guide for conducting risk assessments — providing detailed guidance on preparing for, conducting, communicating, and maintaining risk assessments.	The procedural reference for performing risk assessments in a NIST-aligned enterprise.
FAIR	Factor Analysis of Information Risk — a quantitative risk analysis model defining the factors that contribute to risk and how they combine, expressed in financial terms.	The principal framework for cyber risk quantification; used for financial analysis and risk-informed decision-making.
COSO ERM	Enterprise Risk Management — Integrating with Strategy and Performance. A framework for enterprise-wide risk management, linking risk to strategy and performance.	The reference framework for enterprise risk management; used where cyber risk must integrate with broader enterprise risk.
OCTAVE	Operationally Critical Threat, Asset, and Vulnerability Evaluation — an asset-driven risk assessment method emphasising organisational risk and self-direction.	Used particularly in organisations that wish to conduct assessments internally with minimal external dependence.
NIST CSF	The Cybersecurity Framework — not a risk management framework as such, but a structure for organising security activities that is frequently used as the interface between risk management and the security programme.	Widely used to organise the security programme and to communicate with governance bodies.

ISO 31000 — the general framework

ISO 31000 provides the reference model from which most other risk management frameworks derive. Its principal contributions are:

Principles. Risk management should be integrated, structured and comprehensive, customised, inclusive, dynamic, best-available-information based, human-and-cultural-factors aware, and continually improved.
Framework. Leadership and commitment, integration into organisational processes, design, implementation, evaluation, and improvement — describing how risk management is embedded in the organisation.
Process. Communication and consultation, scope and context, risk identification, risk analysis, risk evaluation, risk treatment, and monitoring and review — the iterative cycle that constitutes risk management activity.
Deliberate non-prescription. ISO 31000 does not define scales, methods, or criteria — it defines the structure within which an enterprise selects its own. This is a strength for adaptability and a weakness for organisations seeking prescriptive guidance.

ISO/IEC 27005 — information security risk management

ISO/IEC 27005 applies the ISO 31000 process to information security. Its principal contributions are:

Asset-based identification. Risk is identified by identifying assets, the threats that could affect them, and the vulnerabilities that could be exploited.
Detailed analysis guidance. Guidance on assessing likelihood and impact, including the factors that influence each.
Evaluation against criteria. Risk is evaluated against defined criteria — risk appetite, tolerances, or acceptance thresholds — to determine whether treatment is required.
Treatment options. Four options — modify (mitigate), retain (accept), avoid, and share (transfer) — with guidance on selecting among them.
Integration with ISO/IEC 27001. The framework is designed to support the risk assessment requirements of the ISMS standard.

NIST Risk Management Framework

The NIST RMF (SP 800-37) defines a seven-step process, tightly coupled to the NIST control catalogue:

Prepare

Establish the context — organisational risk strategy, risk tolerance, roles, and the resources required for the process.

Categorise

Categorise the system based on the impact of a compromise — using FIPS 199 impact levels of low, moderate, or high across confidentiality, integrity, and availability.

Select

Select the controls appropriate to the categorisation — using the SP 800-53 catalogue, tailored to the system and supplemented as required.

Implement

Implement the selected controls and document how each is implemented.

Assess

Assess whether the controls are implemented correctly and operating as intended — through testing and evaluation.

Authorise

A designated authority makes a risk-based decision to authorise the system to operate — accepting the residual risk on behalf of the organisation.

Monitor

Continuously monitor the system and its controls — for changes in risk, control effectiveness, and the operating environment.

The RMF's distinguishing characteristic is its integration of risk management with the control catalogue and with a formal authorisation decision. Its strength is rigour and defensibility; its weakness is complexity and the volume of documentation it requires.

FAIR — quantitative risk analysis

FAIR (Factor Analysis of Information Risk) is the principal framework for expressing cyber risk in financial terms. It decomposes risk into measurable factors:

Risk = Loss Event Frequency × Loss Magnitude. The two top-level factors.
Loss Event Frequency = Threat Event Frequency × Vulnerability. How often does a threat act against the asset, and how often does it succeed?
Threat Event Frequency = Contact Frequency × Probability of Action. How often does the threat come into contact with the asset, and how likely is it to act?
Vulnerability = Threat Capability vs Resistance Strength. How capable is the threat relative to the resistance of the asset?
Loss Magnitude = Primary Loss + Secondary Loss. Direct losses from the event plus consequential losses — regulatory, reputational, legal.

FAIR's contribution is that it makes every factor in the risk equation explicit and estimable — permitting ranges and probability distributions rather than point estimates, and producing risk expressed as an annualised loss exposure. This permits cyber risk to be compared directly with other business risks and used in financial decision-making.

COSO ERM — enterprise risk management

COSO ERM provides the reference framework for enterprise-wide risk management, linking risk to strategy and performance. Its principal contributions:

Integration with strategy. Risk is considered in strategy-setting, not only in operations — the recognition that the biggest risks frequently come from strategic choices.
Governance and culture. The board's risk oversight responsibilities and the enterprise's risk culture are addressed explicitly.
Five components. Governance and culture, strategy and objective-setting, performance, review and revision, and information, communication, and reporting.
Twenty principles. Detailed principles under each component, providing a structure for assessing ERM maturity.
Portfolio view. The enterprise risk portfolio — considering risks together, not only individually — including aggregation and correlation.

Selecting and combining frameworks

Enterprises rarely adopt a single framework in isolation. Common combinations:

ISO/IEC 27005 within an ISO/IEC 27001 ISMS. The most common combination where certification is required.
NIST RMF with SP 800-53 controls. Common in US federal and defence contexts, and in organisations that prefer a control catalogue approach.
ISO 31000 as the enterprise framework, with ISO/IEC 27005 for cyber. Common where cyber risk must integrate with enterprise-wide risk management.
FAIR for quantification. Frequently used alongside a qualitative framework — the qualitative framework for breadth, FAIR for the significant risks.
COSO ERM as the enterprise framework, with NIST CSF for the security programme. Common in sectors where enterprise risk management is mature and cyber risk must be integrated.

The failure mode is adopting multiple frameworks without integration — producing parallel risk registers, duplicate assessments, and reporting that satisfies each framework separately while leaving the underlying risk management weak.

The most useful framing

The most useful framing for risk management frameworks is that they answer different questions. ISO 31000 answers how should risk management be structured? ISO/IEC 27005 answers how should information security risk be assessed? NIST RMF answers how should controls be selected and authorised? FAIR answers how much will this cost? COSO ERM answers how does risk connect to strategy? An enterprise may need answers to several of these — but the frameworks should be integrated into a single coherent process, not operated in parallel.

05 The risk management process

Beneath the frameworks lies a common process. It is iterative rather than linear — assessment informs treatment, treatment changes the risk, monitoring detects the change, and the cycle repeats.

The process

Establish context Define the scope — which business objectives, which assets, which systems, which threats — and the criteria against which risk will be evaluated. Establish the risk appetite and tolerances that will be applied. Identify the participants and their roles.

Identify risk Determine what could happen — the threats, vulnerabilities, and scenarios that could affect the assets in scope. Use multiple techniques to ensure coverage.

Analyse risk Assess the likelihood and impact of each identified risk — using qualitative, semi-quantitative, or quantitative methods appropriate to the significance of the risk and the available data. Consider existing controls and determine residual risk.

Evaluate risk Compare the assessed risk against the criteria established in the context — against risk appetite and tolerances — to determine whether the risk is acceptable or requires treatment. Prioritise by significance.

Treat risk Select and implement a treatment — mitigate, transfer, accept, or avoid. Define the treatment plan, the owner, the timeline, and the expected residual risk after treatment.

Monitor and review Monitor the risk, the controls, and the environment — detecting changes in likelihood or impact, changes in control effectiveness, and new risks. Review the assessment periodically and when circumstances change.

Communicate and consult Throughout the process — engaging stakeholders, reporting to governance bodies, consulting with risk owners, and ensuring that risk information reaches the people who need it.

Iteration and continuous operation

The process is frequently depicted as linear — identification, then assessment, then treatment, then monitoring — but in operation it is continuous and iterative:

Monitoring detects new risks that re-enter the identification step.
Treatment changes the risk that was assessed, requiring re-assessment.
Incidents and near-misses provide evidence that challenges the original assessment.
Business change alters the context, requiring the scope and criteria to be revisited.
Threat intelligence changes the likelihood assessment for specific risks.
Control testing reveals whether controls are operating effectively, changing the residual risk assessment.

The practical implication is that risk management is not an annual project. It is a continuous process, with periodic formal assessment and continuous monitoring and update.

Risk assessment at different levels

Risk assessment is performed at different levels for different purposes:

Levels of risk assessment
Level	Scope	Purpose	Frequency
Enterprise	The whole organisation — its strategy, its portfolio, its aggregate exposure	Board and executive oversight; risk appetite setting; aggregate reporting; capital and investment allocation	Annual, with quarterly monitoring
Business unit or function	A business unit, a function, or a major process	Local risk management; prioritisation of local resources; contribution to enterprise risk	Annual
System or asset	A specific system, service, or asset	Control selection; authorisation decisions; remediation prioritisation	At change, and periodically
Change or project	A specific change, project, or initiative	Identifying the risk introduced by the change; gating the decision to proceed	At initiation and at defined gates
Third party	A supplier, partner, or service provider	Assessing the risk the engagement introduces; informing contracting and assurance	At engagement and periodically
Incident or event	A specific incident, near-miss, or emerging threat	Understanding the exposure revealed; determining whether treatment is required	On occurrence

The levels are connected: system-level assessments aggregate into business-unit assessments, which aggregate into enterprise risk. This aggregation is one of the more difficult aspects of risk management, because risk does not simply add — it correlates, compounds, and concentrates.

The most useful framing

The most useful framing for the risk management process is that it is a decision-support mechanism, not a reporting exercise. Every step exists to inform a decision: what to prioritise, what to fund, what to accept, what to escalate, what to stop doing. If a step produces documentation but no decision, it is not adding value. The question to ask of any risk management activity is: what decision will this inform?

06 Risk identification

Risk identification determines what could happen. It is the step at which the enterprise's imagination is tested — because a risk that is not identified cannot be assessed, treated, or monitored.

Approaches to identification

Approaches to risk identification
Approach	Method	Strengths and limitations
Asset-based	Identify assets, then the threats that could affect each and the vulnerabilities that could be exploited.	Systematic and comprehensive within scope; dependent on the quality of the asset inventory; can miss threats that do not map to a single asset.
Threat-based	Start from the threat landscape — adversary groups, attack techniques, and known campaigns — and identify where the enterprise is exposed.	Threat-informed; effective against capable adversaries; requires threat intelligence; can neglect non-adversarial risks such as error and failure.
Scenario-based	Develop plausible attack or failure scenarios end-to-end — from initial access through to consequence — and identify the risk each represents.	Business-relevant; produces narratives that communicate well; can be time-consuming; coverage depends on the scenarios selected.
Control-based	Start from the control framework — identify where controls are absent, weak, or ineffective, and derive the risk.	Connects directly to the control environment; supported by frameworks such as NIST SP 800-53; can be compliance-driven rather than risk-driven.
Process-based	Walk through business processes and identify where they could fail, be disrupted, or be exploited.	Business-aligned; identifies operational risk; requires process documentation and business engagement.
Data-driven	Use incident data, vulnerability data, threat intelligence, and control monitoring to identify where risk is concentrated.	Evidence-based; identifies risks that are actually materialising; dependent on the quality of the data.
Workshop-based	Structured workshops with business, technology, and security participants to identify risks collectively.	Brings diverse perspectives; builds ownership; can be dominated by the loudest voice; requires skilled facilitation.
Checklist-based	Use published checklists, taxonomies, or catalogues of known risks.	Ensures coverage of known risk categories; efficient; can miss enterprise-specific or novel risks.

Effective identification combines several approaches. Checklists ensure coverage of known categories; workshops bring enterprise-specific knowledge; threat intelligence identifies adversary-relevant risks; incident data identifies what is actually materialising; and scenario development tests the enterprise's imagination.

Sources of risk information

Asset inventory. What the enterprise owns, operates, and depends on — the foundation of asset-based identification.
Threat intelligence. What adversaries are doing — their capabilities, their targets, and their techniques. Examined in Unit 3.
Vulnerability data. What weaknesses exist — from scanning, from penetration testing, from vendor advisories, from bug bounty programmes.
Incident data. What has actually happened — internal incidents, industry incidents, and near-misses.
Control assessment. Where controls are absent or ineffective — from audit, from testing, from monitoring.
Business context. What the business is trying to achieve — new markets, new products, acquisitions, digitalisation — and the risk that creates.
Regulatory and legal landscape. What obligations apply, and what changes are anticipated.
Third-party dependencies. What the enterprise depends on — suppliers, service providers, partners, and their own exposures.
Industry and peer experience. What has happened to comparable organisations — a productive source of scenarios that the enterprise may not have considered.
Emerging technology. New technology the enterprise is adopting or considering — and the risk it introduces.

Structuring identified risks

Identified risks should be recorded consistently. A well-formed risk statement typically includes:

The cause. The threat, vulnerability, or condition that creates the risk.
The event. What would happen — the threat event.
The consequence. What the effect would be — the impact on the enterprise.

A common format is:

Because [cause], [event] may occur, which would result in [consequence].

For example:

"Because privileged access is not subject to multi-factor authentication, an attacker who obtains a privileged credential may gain administrative access to production systems, which would result in unauthorised modification or exfiltration of customer data."
"Because the enterprise depends on a single cloud provider for its customer-facing services, a provider outage may make those services unavailable, which would result in lost revenue and regulatory notification obligations."
"Because backup restoration has not been tested, a ransomware incident may render backups unusable, which would result in extended service interruption and potential payment of a ransom."

The format forces clarity. A risk stated as "ransomware" is not a risk statement — it is a threat. A risk stated in the cause-event-consequence format identifies what is creating the risk, what would happen, and what the effect would be — which is what is required to assess and treat it.

Common failures in identification

Stopping at the first plausible risk. Identification is a divergent activity — the objective is coverage, not precision. The first risk identified is rarely the most significant.
Confusing threats, vulnerabilities, and risks. A threat is not a risk; a vulnerability is not a risk. A risk is the combination of these with consequence.
Identifying only technical risks. Many of the most significant cyber risks are organisational — third-party dependence, skills shortage, governance gaps, culture.
Neglecting low-likelihood, high-impact risks. These are frequently the most consequential and the least likely to be identified, because they have not yet occurred.
Assuming the existing control environment. Identification should consider the inherent risk before assuming that controls reduce it.
Failing to involve the business. Identification conducted by the security team alone will identify technical risks and miss business risks — the ones that matter most.
Not updating. Identification is not a one-time activity. New threats, new technology, new business activities, and new dependencies all create new risks.

The most consequential identification failure

The most consequential identification failure is limiting the exercise to risks the enterprise has already considered. Risk registers tend to accumulate the same categories year after year — phishing, ransomware, insider threat, third-party breach — because they are the risks everyone knows. The risks that cause the greatest harm are frequently the ones that were not on the list: an unusual dependency, a non-obvious aggregation, a scenario the enterprise had never imagined. Deliberate effort to identify what is not on the list is the most valuable — and most frequently skipped — part of identification.

07 Risk assessment and analysis

Risk analysis determines how significant each identified risk is. It assesses likelihood and impact, considers the effect of existing controls, and produces a residual risk estimate that can be evaluated against appetite and prioritised against other risks.

Assessing likelihood

Likelihood assessment considers:

Threat capability and intent. Is there an adversary with the capability and motivation to exploit this? How capable are they relative to the enterprise's defences?
Exposure. How accessible is the asset or the vulnerability to the threat? Is it internet-facing? Is it accessible to insiders? Is it in a trusted network segment?
Vulnerability. How easily could the weakness be exploited? Is there a public exploit? Does it require specialised knowledge or privileged access?
Control effectiveness. What controls exist, and how effective are they? Have they been tested?
Historical frequency. How often has this type of event occurred — in the enterprise, in the sector, or in comparable organisations?
Threat intelligence. Is there current intelligence indicating active exploitation, targeting of the enterprise's sector, or campaigns against comparable organisations?

Assessing impact

Impact assessment considers the consequence of the risk materialising. Impact is frequently assessed across multiple dimensions:

Dimensions of impact
Dimension	Considerations
Financial	Direct losses — remediation cost, lost revenue, legal costs, regulatory fines. Indirect losses — customer churn, increased cost of capital, investment in remediation.
Operational	Service interruption, loss of production, degradation of service quality, inability to perform critical processes.
Regulatory and legal	Regulatory findings, fines, enforcement action, litigation, contractual breach, notification obligations.
Reputational	Loss of customer trust, media coverage, brand damage, difficulty recruiting and retaining staff, loss of business partners.
Safety and environmental	Injury, loss of life, environmental release — relevant particularly to critical infrastructure and operational technology, as examined in Lesson 5.8.
Strategic	Loss of competitive advantage, inability to pursue a strategic objective, loss of intellectual property, loss of market position.
Privacy	Harm to individuals whose data is affected — financial loss, identity theft, discrimination, distress — with associated regulatory and reputational consequence.

Assessing control effectiveness

The assessment of residual risk depends on the effectiveness of existing controls. Assessing control effectiveness requires considering:

Design effectiveness. Is the control designed to address the risk? A control that does not address the mechanism by which the risk would materialise is not effective, however well it operates.
Operating effectiveness. Is the control actually operating as designed? Has it been tested? Are there known failures?
Coverage. Does the control apply to the whole scope of the risk? A control that covers 80% of systems leaves 20% exposed.
Reliability. How consistently does the control work? Does it depend on human action, which may be inconsistent, or is it automated?
Independence. Can the control be bypassed by the threat? A control that the adversary can disable or circumvent provides less assurance.
Compensating controls. Where the primary control is not in place, what compensating controls exist, and how effective are they?

A common failing is to assume control effectiveness without evidence — to treat the presence of a control as equivalent to its effectiveness. Assessment should be based on testing, monitoring, and evidence, not on assumption.

Qualitative assessment methods

Qualitative assessment uses descriptive scales. A typical approach uses a five-point scale for likelihood and impact, with defined criteria for each level:

Example qualitative likelihood and impact scales
Level	Likelihood	Impact
1 — Very low	Expected less than once in 10 years	Negligible — no material effect
2 — Low	Expected once in 5–10 years	Minor — limited effect, absorbed within normal operations
3 — Medium	Expected once in 1–5 years	Moderate — significant effect, requires management attention
4 — High	Expected at least once per year	Major — serious effect on objectives, regulatory or reputational consequence
5 — Very high	Expected multiple times per year	Severe — existential threat, loss of licence to operate, safety consequence

Likelihood and impact are combined in a risk matrix:

Example 5×5 risk matrix
Impact ↓ / Likelihood →	1 Very low	2 Low	3 Medium	4 High	5 Very high
5 Severe	5	10	15	20	25
4 Major	4	8	12	16	20
3 Moderate	3	6	9	12	15
2 Minor	2	4	6	8	10
1 Negligible	1	2	3	4	5

The matrix is typically combined with a risk acceptance threshold — a score above which treatment is required, escalation is triggered, or acceptance must be at a higher level.

Weaknesses of risk matrices

Risk matrices are widely used and widely criticised. The principal weaknesses:

Range compression. A 25-point scale compresses a wide range of actual risk into a small number of categories — so that risks of very different magnitudes receive the same rating.
Multiplication of ordinal scales. Likelihood and impact are ordinal (1st, 2nd, 3rd) but are multiplied as if cardinal (1, 2, 3) — which is mathematically questionable.
Inconsistency between assessors. Different assessors rate the same risk differently — because the criteria require interpretation and because assessors have different risk tolerances.
Focus on the centre. Risks cluster in the middle of the matrix, because assessors are reluctant to rate extremes — producing a false concentration and obscuring genuine differences.
Inability to aggregate. Risk scores cannot be summed or compared across different types of risk — a score of 12 from likelihood 4 × impact 3 is not the same as a score of 12 from likelihood 3 × impact 4.
False precision. A score of "12" implies a precision that the underlying judgement does not support.

These weaknesses do not make matrices useless — they make them a communication and prioritisation tool rather than a measurement instrument. Where the significance of the decision warrants it, quantitative analysis should be used.

Semi-quantitative approaches

Semi-quantitative approaches attempt to bridge the gap between qualitative and quantitative:

Calibrated scales. Defining what each level of the scale means in measurable terms — for example, "High likelihood = expected at least once per year."
Anchored scales. Anchoring the assessment to specific reference points — comparing the risk to a known event or a defined financial threshold.
Weighted factors. Assigning weights to different impact dimensions and combining them into a composite score.
Ranges rather than points. Assessing likelihood and impact as ranges rather than single values, and combining the ranges to produce a risk range.

The most useful framing

The most useful framing for risk assessment is that the method should be proportionate to the decision it informs. A decision about whether to remediate a medium-severity finding in a non-critical system can be made with a qualitative assessment. A decision about whether to invest ten million dollars in a control programme requires quantitative analysis — because the decision is financial and must be justified in financial terms. Matching the method to the decision avoids the twin failures of over-engineering trivial decisions and under-supporting significant ones.

08 Risk evaluation and treatment

Risk evaluation determines whether an assessed risk is acceptable or requires treatment. Risk treatment determines what will be done about it. Together they convert assessment into action.

Risk evaluation

Risk evaluation compares the assessed residual risk against the criteria established in the context step — typically the enterprise's risk appetite and the tolerances derived from it.

The evaluation produces one of three outcomes:

The risk is within appetite. It can be accepted by the accountable owner at the appropriate level, documented, and monitored.
The risk exceeds appetite but is within tolerance. It requires treatment, or formal acceptance at a higher level than the routine owner.
The risk exceeds tolerance. It requires treatment, escalation to the executive or board, and potentially immediate action.

Evaluation also considers prioritisation. Where multiple risks require treatment, the enterprise must decide what to do first — based on the magnitude of the risk, the cost of treatment, the feasibility of treatment, and the alignment with strategic objectives.

Risk treatment options

The four risk treatment options
Option	Description	When appropriate
Mitigate (modify)	Implement controls to reduce likelihood, impact, or both.	Where the risk exceeds appetite and controls can reduce it cost-effectively. The most common treatment.
Transfer (share)	Shift the risk to another party — through insurance, through contract, or through outsourcing.	Where another party is better able to bear or manage the risk, or where insurance provides appropriate coverage. Note that accountability is not transferred — only the financial consequence.
Accept (retain)	Formally accept the risk, with documented rationale and appropriate authority.	Where the risk is within appetite, or where treatment would cost more than the risk is worth, or where treatment is not feasible. Requires formal acceptance by an authorised individual.
Avoid	Eliminate the risk by discontinuing the activity that creates it.	Where the risk exceeds tolerance and cannot be adequately mitigated, and the activity is not essential. Frequently the correct answer for business activities that carry disproportionate risk.

Selecting treatments

Treatment selection considers:

Effectiveness. How much will the treatment reduce the risk? Will it reduce likelihood, impact, or both?
Cost. What will the treatment cost — to implement, to operate, and to maintain?
Feasibility. Can the treatment be implemented given the enterprise's technology, skills, and operational constraints?
Time. How long until the treatment reduces the risk? Some treatments take months or years to implement.
Side effects. Does the treatment introduce new risk, affect operational efficiency, or create dependency on a new supplier?
Residual risk. What risk remains after treatment, and is it within appetite?
Reversibility. If the treatment proves ineffective or inappropriate, can it be reversed?

The treatment decision should be recorded — what was decided, why, by whom, and what the expected residual risk is. This record is what makes the decision defensible and what permits later assessment of whether the treatment worked.

Treatment planning

Where treatment is selected, a plan is required. A treatment plan typically includes:

The risk being treated. A reference to the risk register entry.
The selected treatment. The option selected and the specific controls to be implemented.
The owner. The individual accountable for implementing the treatment.
The timeline. When the treatment will be implemented, with milestones.
The resources. What is required — budget, personnel, technology.
The expected outcome. The expected residual risk after treatment.
The evidence. What will demonstrate that the treatment has been implemented and is effective.
The interim position. What happens between now and implementation — whether interim controls are required, and whether the risk is accepted temporarily.

Treatment in practice

In practice, treatment decisions are constrained:

Not all risks can be mitigated. Legacy systems, third parties, and dependencies on technology the enterprise does not control may not be amenable to control.
Mitigation is frequently partial. A control may reduce likelihood substantially but not eliminate it — leaving residual risk that must be accepted or further treated.
Transfer is limited. Cyber insurance covers some financial consequence but not reputational damage, regulatory action, or loss of customer trust. Contractual transfer frequently fails in practice when the supplier is unable to bear the loss.
Acceptance requires authority. Accepting a risk above tolerance requires an individual with the authority to make that decision — typically an executive or the board.
Avoidance is frequently overlooked. Discontinuing an activity is rarely considered, yet it is sometimes the correct answer — particularly for business activities that carry disproportionate risk relative to their value.
Treatments interact. Implementing one control may affect other risks — positively or negatively. A treatment for one risk can create or exacerbate another.

The most useful framing

The most useful framing for risk treatment is that the objective is not to eliminate risk, but to bring it within appetite at an acceptable cost. Elimination is rarely possible and frequently not worth the cost. The question is not "how do we eliminate this risk?" but "what is the most cost-effective way to reduce this risk to a level we are willing to carry?" That reframing permits proportionate treatment, makes the cost-benefit explicit, and acknowledges that the enterprise will carry residual risk.

09 Risk monitoring and reporting

Risk management does not end with treatment. Risks change, controls degrade, the environment shifts, and new risks emerge. Monitoring detects those changes; reporting ensures that the people who need to know — and who can act — are informed.

What to monitor

The risk itself. Has the likelihood or impact changed? New threat intelligence, new vulnerabilities, or changed exposure may alter the assessment.
Control effectiveness. Are the controls that reduce the risk still operating effectively? Have they degraded, been bypassed, or become obsolete?
Treatment progress. Is the treatment plan on track? Are milestones being met? Are there obstacles?
Residual risk. What is the current residual risk — after treatment, after control degradation, after changes in the environment?
New risks. Has anything changed that introduces new risk — new technology, new business activity, new supplier, new regulation?
Risk appetite compliance. Is the enterprise operating within appetite? Where is it exceeding tolerance?
Risk aggregation. Are individual risks combining into a larger aggregate exposure?

Key risk indicators

Key risk indicators (KRIs) are metrics that provide early warning of increasing risk exposure. They are leading indicators — they measure conditions that predict risk, rather than risk events that have already occurred.

Example key risk indicators
Risk	Example KRIs
Unpatched vulnerabilities	Number of critical vulnerabilities beyond remediation SLA; mean time to patch by severity; percentage of systems within patch compliance.
Credential compromise	Percentage of accounts with MFA enabled; number of privileged accounts; number of dormant accounts; failed authentication trends.
Third-party risk	Percentage of critical suppliers assessed within 12 months; suppliers with open findings; concentration measures.
Insider risk	Number of users with excessive privileges; access review completion rate; number of exceptions to least privilege.
Detection capability	Percentage of systems with logging enabled; percentage of logs ingested into SIEM; mean time to detect.
Recovery capability	Percentage of backups tested; time since last restoration test; recovery time objective achievement.
Security culture	Phishing simulation click rate; report rate; training completion; security incidents reported by staff.
Exception position	Number of open exceptions; average exception age; exceptions past expiry.

Effective KRIs are:

Predictive. They measure conditions that precede risk events, not the events themselves.
Actionable. A change in the indicator suggests a specific action.
Measurable. Based on data that can be collected consistently.
Thresholded. With defined levels that trigger escalation or action.
Owned. With a named individual accountable for monitoring the indicator and responding.
Few. A small number of indicators that are genuinely monitored is more useful than a comprehensive dashboard that no one watches.

Risk reporting

Risk reporting ensures that risk information reaches the people who need it. Different audiences require different reporting:

Risk reporting by audience
Audience	What they need	Format and cadence
Board	Aggregate risk position against appetite; significant risks and their trajectory; incidents and their implications; regulatory matters; major investment decisions.	Concise dashboard, quarterly.
Executive	Detailed risk position; treatment progress; resource requirements; cross-functional issues; decisions required.	Detailed report, monthly or quarterly.
Risk owners	The risks they own, their status, treatment progress, and any changes in assessment.	Operational report, monthly.
Security steering committee	The risk register; treatment priorities; exceptions; policy implications; resource allocation.	Detailed review, quarterly.
Internal audit	The risk register and risk assessments as inputs to the audit plan; risk management process effectiveness.	As required for planning and assessment.
Regulators	Compliance with risk management obligations; specific risks where required; incident reporting.	As defined by the regulatory regime.

Board risk reporting

Board reporting is the most consequential and the most frequently mishandled. Effective board risk reporting:

Is consistent. The same structure and metrics each period, so that change is visible.
Expresses risk, not activity. The board needs to understand exposure, not how many projects are in flight or how many controls have been deployed.
Shows direction of travel. Whether the enterprise is becoming more or less exposed — which requires comparison over time.
Is aligned to appetite. Structured around the risk categories in the appetite statement, showing position against tolerance.
Includes leading indicators. Not only what has happened, but what is likely to happen.
Highlights decisions required. The board should know what it is being asked to decide — risk acceptance, investment, strategic change.
Is honest. Reporting that presents only favourable news deprives the board of the information it needs and undermines credibility when reality becomes apparent.
Permits challenge. Enough detail and context that the board can test management's assertions.

Monitoring and the risk management cycle

Monitoring closes the loop. The information it produces feeds back into identification (new risks), assessment (changed likelihood or impact), evaluation (whether risks remain within appetite), and treatment (whether treatments are working). Risk management is not a linear process that concludes — it is a cycle that continues.

The most useful framing

The most useful framing for monitoring and reporting is that risk management is only as good as its feedback loop. Assessment without monitoring produces a snapshot that becomes progressively more inaccurate. Treatment without monitoring produces action that may or may not be achieving its purpose. And reporting without monitoring produces assurance that is based on assumption rather than evidence. The feedback loop is what makes risk management a living process rather than a periodic documentation exercise.

10 Cyber risk quantification

Cyber risk quantification is the discipline of expressing cyber risk in financial terms. It matters because financial expression permits cyber risk to be compared with other business risks, to be evaluated against the cost of controls, and to be used in financial decision-making.

Why quantification matters

It permits comparison. Cyber risk can be compared with other enterprise risks — market risk, credit risk, operational risk — on a common basis.
It supports investment decisions. A control that costs $500,000 and reduces expected annual loss from $2M to $500,000 has a quantifiable return. A control that costs $500,000 and reduces a risk from "High" to "Medium" does not.
It informs risk appetite. An appetite expressed as "low" is difficult to apply. An appetite expressed as "no more than $5M expected annual loss from cyber risk" is applicable to decisions.
It supports insurance decisions. Quantification informs the decision about how much insurance to buy, what limits are appropriate, and whether the premium is justified.
It engages executives and boards. Financial expression speaks the language of the boardroom in a way that qualitative ratings do not.
It reveals what matters. The process of quantification frequently reveals that the enterprise's assumptions about what matters most are wrong.

The FAIR model in detail

FAIR (Factor Analysis of Information Risk) is the most widely used quantification model. Its structure:

FAIR taxonomy
Level	Factors
Risk	Loss Event Frequency × Loss Magnitude
Loss Event Frequency	Threat Event Frequency × Vulnerability
Threat Event Frequency	Contact Frequency × Probability of Action
Vulnerability	Threat Capability vs Resistance Strength
Loss Magnitude	Primary Loss + Secondary Loss
Primary Loss	Direct costs of the event — remediation, response, legal, regulatory
Secondary Loss	Consequential costs — reputation, customer churn, increased cost of capital, lost business

Each factor is estimated as a range or a probability distribution rather than a point estimate — reflecting the uncertainty inherent in risk. Monte Carlo simulation is then used to combine the distributions and produce a distribution of possible outcomes.

Conducting a FAIR analysis

Scope the analysis

Define the asset or scenario being analysed — what is at risk, and what event is being assessed.

Identify the threat community

Determine who or what could cause the event — a specific adversary group, a category of attacker, or an accidental event.

Estimate threat event frequency

Estimate how often the threat community would attempt the event — using internal data, industry data, threat intelligence, and expert judgement. Express as a range.

Estimate vulnerability

Estimate how likely the attempt is to succeed given the controls in place — considering threat capability and resistance strength.

Estimate primary loss

Estimate the direct costs if the event occurs — response, remediation, legal, regulatory, and replacement costs.

Estimate secondary loss

Estimate the consequential costs — customer churn, reputational damage, increased cost of capital, lost business opportunities.

Run the model

Combine the distributions through Monte Carlo simulation to produce a distribution of possible annualised loss.

Interpret and communicate

Express the results — typically as a range with a most likely value, and as a probability of exceeding defined thresholds.

Obtaining data

Quantification is frequently constrained by the availability of data. Sources include:

Internal incident data. The enterprise's own incident history — frequency, cost, and control performance.
Industry data. Sector incident reporting, industry surveys, and threat intelligence reports.
Regulatory data. Breach notification databases and regulatory enforcement records.
Vendor and insurer data. Cyber insurers publish loss data; vendors publish threat and vulnerability data.
Expert judgement. Where data does not exist, calibrated expert estimation — frequently using structured techniques such as the Delphi method or calibrated probability assessment.
Control assessment data. Testing results, monitoring data, and audit findings — informing the vulnerability assessment.

Where data is limited — which is frequently the case — the honest response is to express wide ranges and high uncertainty, rather than to present a precise figure based on weak assumptions.

Limitations of quantification

Data scarcity. Cyber risk is characterised by low-frequency, high-impact events — for which there is little historical data. Estimating the frequency of an event that has never occurred is inherently uncertain.
Non-stationarity. The threat environment changes rapidly. Historical data may be a poor predictor of future risk when the threat landscape, the technology, and the enterprise's exposure are all changing.
Model dependence. The output of a quantitative model depends heavily on its assumptions. A model that produces a precise number conveys more confidence than the underlying assumptions justify.
Difficulty of estimating secondary loss. Reputational damage, customer churn, and long-term business impact are notoriously difficult to estimate and frequently dominate the total.
Tail risk. The most consequential events are the least amenable to quantification — the extreme tail of the distribution, where the enterprise's survival may be at stake.
False precision. The presentation of a single figure — "$4.2M expected annual loss" — conveys precision that does not exist and can be misleading in decision-making.

Using quantification appropriately

Quantification is most useful when:

The decision is financial. Investment decisions, insurance decisions, and capital allocation decisions all benefit from financial expression.
The risk is significant enough to warrant the effort. Quantifying a minor risk is not worth the time.
Comparison is required. Where cyber risk must be compared with other business risks, or where alternative treatments must be compared.
The organisation is prepared for the answer. A quantified risk may reveal an exposure the enterprise is unwilling to address — and quantification without the capacity to respond can be counterproductive.
Uncertainty is communicated honestly. Results should be presented as ranges with explicit uncertainty, not as point estimates.
The model is transparent. The assumptions, the data sources, and the method should be documented and challengeable.

The most consequential quantification failure

The most consequential quantification failure is presenting false precision — a single figure, calculated from weak data and untested assumptions, that is then treated as fact. A quantification exercise that produces "$7.3M expected annual loss" from assumptions that could reasonably produce anything between $500,000 and $50M has not informed a decision; it has obscured it. Quantification is valuable when it structures thinking, identifies the factors that matter, and expresses uncertainty honestly. It is dangerous when it substitutes a number for judgement.

11 Risk registers and risk ownership

The risk register is the record of the enterprise's risks — what they are, how significant they are, who owns them, and what is being done about them. It is the operational heart of risk management, and one of the more frequently misunderstood artefacts in the security programme.

What a risk register is

A risk register is a living record of the risks the enterprise has identified, with enough information to support management and reporting. It is not:

A list of vulnerabilities. A vulnerability is a weakness; a risk is the combination of a threat, a vulnerability, and a consequence.
A list of audit findings. Findings may identify risk, but they are not risks in themselves.
A compliance artefact. A register maintained to satisfy an auditor, and not used to make decisions, is not a risk register — it is documentation.
A static document. A register that is not updated as risks change is a historical record, not a management tool.
A technical document. The register should be comprehensible to the business owners who use it, not only to the security team.

Register content

A well-constructed register entry typically includes:

Risk register fields
Field	Content
Risk ID	A unique identifier, for reference in reporting and decisions.
Risk title	A short descriptive name.
Risk statement	The cause-event-consequence statement — what creates the risk, what would happen, what the effect would be.
Risk category	The category to which the risk belongs — technical, third-party, insider, availability, regulatory, and so on.
Assets affected	What the risk would affect — systems, data, processes, people.
Risk owner	The named individual accountable for the risk.
Inherent likelihood	The likelihood before controls.
Inherent impact	The impact before controls.
Existing controls	The controls currently in place that reduce the risk.
Control effectiveness	An assessment of how effective the existing controls are.
Residual likelihood	The likelihood after existing controls.
Residual impact	The impact after existing controls.
Residual risk rating	The combined residual risk.
Treatment	The selected treatment — mitigate, transfer, accept, or avoid.
Treatment plan	What will be done, by whom, by when, and at what cost.
Target residual risk	The expected risk after treatment.
Status	The current status — open, treated, accepted, closed.
Review date	When the risk will next be reviewed.
Last updated	When the entry was last modified, and by whom.

Not every enterprise needs every field. The register should contain what is required to manage the risk and to report on it — no more and no less. Registers with eighty fields are frequently unmaintained; registers with six may be inadequate for decision-making.

Risk ownership

Risk ownership is the assignment of accountability for a risk to a named individual. It is the single most important determinant of whether a risk will be managed.

Principles of risk ownership:

The owner should be a single individual. Accountability cannot be shared. A risk owned by a committee is a risk owned by no one.
The owner should have authority over the risk. An owner who cannot influence the risk — who cannot implement controls, allocate resources, or change the business activity that creates the risk — is not positioned to manage it.
The owner should be at the right level. A risk that affects the whole enterprise should be owned at executive level; a system-specific risk at the level accountable for that system.
The owner should understand the risk. Owners who have not been engaged in the assessment are unlikely to engage in the treatment.
The owner should be accountable for treatment. The owner is not necessarily the person who implements the treatment, but is accountable for it being implemented.
The owner should accept the residual risk. Where treatment leaves residual risk, the owner formally accepts it — or escalates it if it exceeds their authority.

Common ownership failures

Ownership by the security function. Security risks owned by the CISO rather than by the business that carries them — producing accountability without authority.
Ownership by committee. Risks owned by a steering committee, an executive team, or "the business" — so that no individual is accountable.
Ownership without engagement. Risks assigned to owners who were not consulted and who have not accepted the assignment — producing nominal ownership only.
Ownership without authority. Risks assigned to individuals who cannot influence them — producing owners who can only report, not manage.
Ownership drift. Risks reassigned as personnel change, without the new owner being engaged — producing a register in which ownership is stale.

The register as a management tool

A register is valuable when it is used:

To make prioritisation decisions. The register shows where the greatest exposure lies, informing where resources are directed.
To track treatment. The register shows what is being done, by whom, and whether it is on track.
To support escalation. Risks exceeding tolerance are identified in the register and escalated to the appropriate level.
To support reporting. The register provides the raw material for board, executive, and risk owner reporting.
To evidence decisions. The register records what was known, what was decided, and by whom — providing the basis for accountability.
To identify aggregation. A register permits the enterprise to see where multiple risks concentrate on the same asset, dependency, or business process.

Register hygiene

Registers degrade over time unless actively maintained:

Regular review. Each risk should have a review date, and reviews should be conducted.
Closure of closed risks. Risks that no longer exist should be formally closed, with the reason recorded.
Retirement of obsolete entries. Entries referring to systems that no longer exist, or risks that have been fully treated, should be removed from the active register.
Consistent format. Entries should follow a consistent structure, so that the register is usable.
Version control. Changes to the register should be tracked, so that the history of each risk is visible.
Accessibility. The register should be accessible to those who need it — risk owners, governance bodies, audit.
Avoiding bloat. A register with five hundred entries is not usable. Focus on material risks, and manage the rest through routine operational processes.

The most useful framing

The most useful framing for the risk register is that it is a decision-support tool, not a compliance artefact. Its value is not in the completeness of its entries but in whether it is used to make decisions — what to fund, what to remediate, what to accept, what to escalate. A register with ten well-managed risks, used actively to direct resources, is worth far more than a register with a thousand entries that no one consults.

12 Common pitfalls

Risk management programmes fail in predictable ways. Recognising the pitfalls accelerates improvement.

Pitfall 1 — Risk management as a compliance exercise

Conducting risk assessment annually to satisfy an auditor, producing documentation that has no influence on decisions — and conducting it again the following year without reference to what was produced.

Mitigation: Anchor risk management to decisions. Every assessment should inform a specific decision — prioritisation, funding, acceptance, escalation. If it does not, it is not adding value.

Pitfall 2 — No risk appetite to assess against

Assessing risk without a defined appetite or tolerance — so that there is no basis on which to determine whether a risk is acceptable or requires treatment.

Mitigation: Establish risk appetite and tolerances before conducting assessment. Without them, evaluation is subjective.

Pitfall 3 — Every risk is high

Assessment scales that produce a concentration of high ratings — because the criteria are too broad, the assessors are too cautious, or the culture discourages rating anything as low.

Mitigation: Calibrate the scales. Define what each level means. Review assessments for consistency. Force differentiation where ratings cluster.

Pitfall 4 — Risk identified but never treated or accepted

A register full of risks that no one has decided what to do about — exposures that are documented but not managed.

Mitigation: Require a treatment decision for every risk above a defined threshold. Track treatment to closure. Review the register for risks with no decision.

Pitfall 5 — Risks without owners

Risks assigned to committees, departments, or "the business" — so that no individual is accountable for treatment or acceptance.

Mitigation: Assign a named individual owner to every risk. Review ownership as part of register maintenance. Escalate risks where no owner can be identified.

Pitfall 6 — Owners without authority

Risks assigned to owners who cannot influence them — who cannot implement controls, allocate resources, or change the business activity that creates the risk.

Mitigation: Assign ownership at the level where authority exists. Where a risk requires action beyond the owner's authority, escalate to a level where it can be taken.

Pitfall 7 — Risk management performed by security alone

Assessment conducted by the security team without business involvement — producing a technical view of exposure that misses business consequence and that the business does not own.

Mitigation: Involve business and system owners in assessment. Frame risks in business terms. Ensure that business owners own the business risks.

Pitfall 8 — Assessment without monitoring

Risk assessment performed once, with no ongoing monitoring of changes in likelihood, impact, control effectiveness, or the environment — so that the assessment becomes progressively less accurate.

Mitigation: Establish key risk indicators. Review risks on a defined cycle. Trigger reviews when circumstances change. Monitor control effectiveness continuously.

Pitfall 9 — Treatment without verification

Controls implemented in response to a risk, with no verification that they are effective — so that the residual risk assessment is based on assumption rather than evidence.

Mitigation: Define how treatment effectiveness will be verified. Test controls. Reassess residual risk based on evidence, not on the intention of the treatment.

Pitfall 10 — False precision in quantification

Presenting a single financial figure calculated from weak data and untested assumptions, and treating it as fact — obscuring rather than informing the decision.

Mitigation: Express uncertainty explicitly. Present ranges, not points. Document assumptions. Use quantification to structure thinking, not to substitute for judgement.

Pitfall 11 — Risk register bloat

Registers containing hundreds of entries, many of which are vulnerabilities or audit findings rather than risks — so that the register is not usable for management or reporting.

Mitigation: Focus the register on material risks. Manage operational issues through operational processes. Periodically review and rationalise the register.

Pitfall 12 — Aggregation ignored

Risks assessed individually, with no consideration of how they aggregate — so that a large number of individually acceptable risks combine into an unacceptable exposure.

Mitigation: Analyse the register for concentration — on assets, dependencies, business processes, and threat actors. Assess aggregate exposure against appetite.

Pitfall 13 — Failure to close risks

Risks remaining on the register long after they have been treated or have ceased to exist — so that the register overstates current exposure.

Mitigation: Review the register periodically. Close risks that no longer exist. Retire obsolete entries. Keep the register current.

Risk management pitfalls and mitigations
Pitfall	Primary mitigation
Risk management as a compliance exercise	Anchor to decisions; every assessment informs a decision.
No risk appetite to assess against	Establish appetite and tolerances before assessment.
Every risk is high	Calibrate scales; review for consistency; force differentiation.
Risk identified but never treated or accepted	Require a treatment decision for every material risk.
Risks without owners	Assign a named individual owner to every risk.
Owners without authority	Assign ownership where authority exists; escalate where required.
Risk management performed by security alone	Involve business and system owners; frame in business terms.
Assessment without monitoring	Establish KRIs; review on cycle and on trigger.
Treatment without verification	Define verification; test controls; reassess on evidence.
False precision in quantification	Express uncertainty; present ranges; document assumptions.
Risk register bloat	Focus on material risks; rationalise periodically.
Aggregation ignored	Analyse concentration; assess aggregate exposure against appetite.
Failure to close risks	Review the register periodically; close and retire obsolete entries.

The most consequential pitfall

The most consequential pitfall in risk management is treating it as a documentation exercise rather than a decision-making one. Risk registers, assessment reports, and heat maps can all be produced without any of them changing what the enterprise does. The test of risk management is not whether risks are documented, but whether resources have been reallocated, a business initiative altered, remediation prioritised, or a risk formally accepted by a named executive. Risk management that has never changed a decision is not risk management — it is reporting.

13 Key concepts

The terms below are used throughout Unit 6. Capture them in your own words as you work through the lesson.

Risk management: The coordinated activities through which an enterprise directs and controls risk — identification, assessment, treatment, monitoring, and reporting.
Risk: The combination of the likelihood of a threat event and the impact if it occurs. Expressed qualitatively, semi-quantitatively, or quantitatively.
Asset: Anything of value to the enterprise that could be affected by a risk — information, systems, infrastructure, people, processes, reputation.
Threat: Anything that could cause harm to an asset — an adversary, an accident, a natural event, or an error.
Vulnerability: A weakness that a threat could exploit to cause harm.
Threat event: The occurrence of a threat acting against a vulnerability — the point at which potential harm becomes actual harm.
Likelihood: The probability that a threat event will occur — expressed as a frequency, a probability, or a qualitative rating.
Impact: The consequence if a threat event occurs — financial, operational, regulatory, reputational, safety, strategic, or privacy.
Inherent risk: The risk that exists before any controls are applied.
Residual risk: The risk that remains after controls have been applied — the exposure the enterprise actually carries.
Control: A measure that modifies risk — reducing likelihood, reducing impact, or both.
Risk assessment: The overall process of risk identification, risk analysis, and risk evaluation.
Risk analysis: The process of determining the likelihood and impact of an identified risk, considering existing controls.
Risk evaluation: The process of comparing assessed risk against the criteria established in the context — risk appetite and tolerances — to determine whether treatment is required.
Risk treatment: The action taken in response to a risk — mitigate, transfer, accept, or avoid.
Risk mitigation: Implementing controls to reduce likelihood, impact, or both.
Risk transfer: Shifting the financial consequence of a risk to another party — through insurance, contract, or outsourcing. Accountability is not transferred.
Risk acceptance: A formal, documented decision to retain a risk — made by an individual with the authority to do so, within the enterprise's appetite.
Risk avoidance: Eliminating a risk by discontinuing the activity that creates it.
Risk owner: The named individual accountable for a risk — for its treatment, its monitoring, and its acceptance where applicable.
Risk register: The record of the enterprise's identified risks — their assessment, ownership, treatment, and status.
Key risk indicator (KRI): A metric that provides early warning of increasing risk exposure — used to monitor position against risk tolerance.
Risk matrix: A grid combining likelihood and impact to produce a risk rating — widely used for qualitative and semi-quantitative assessment, with recognised limitations.
Risk aggregation: The combination of individual risks into a larger aggregate exposure — including correlation, concentration, and compounding.
ISO 31000: The general risk management standard — principles, framework, and process — deliberately non-prescriptive regarding methods and scales.
ISO/IEC 27005: The information security risk management standard — applying ISO 31000 to information security with detailed guidance on the process.
NIST RMF: The NIST Risk Management Framework (SP 800-37) — a seven-step process for managing security and privacy risk across the system lifecycle.
NIST SP 800-30: The NIST guide for conducting risk assessments — detailed procedural guidance for risk assessment.
FAIR: Factor Analysis of Information Risk — a quantitative risk analysis model decomposing risk into measurable factors and expressing it in financial terms.
COSO ERM: The Committee of Sponsoring Organizations' Enterprise Risk Management framework — linking risk to strategy and performance across the enterprise.
OCTAVE: Operationally Critical Threat, Asset, and Vulnerability Evaluation — an asset-driven risk assessment method emphasising organisational risk.
Annualised loss expectancy (ALE): The expected annual financial loss from a risk — calculated as single loss expectancy multiplied by annualised rate of occurrence.
Monte Carlo simulation: A computational method that combines probability distributions to produce a distribution of possible outcomes — used in quantitative risk analysis.
Calibrated estimation: A structured technique for obtaining expert estimates of uncertain quantities — used where historical data is unavailable.
Risk-based decision: A decision informed by an assessment of the risk involved — the objective of the risk management process.

14 Activities

The activities below help you test your understanding and prepare for the unit discussion and Assignment 3. They are not graded, but completing them will substantially improve your preparation.

Activity 1 — Risk assessment for a business initiative

Choose a business initiative that an enterprise might undertake — migrating a core system to the cloud, adopting a new customer platform, integrating an acquired company, or deploying a new operational technology system. Conduct a risk assessment (600–700 words) covering:

the context — the initiative, the assets affected, and the business objectives it serves;
at least six identified risks, each expressed in the cause-event-consequence format;
an assessment of each risk — likelihood and impact, with the criteria used and the existing controls considered;
the residual risk rating for each, and whether it is within the assumed appetite;
the treatment selected for each risk — mitigate, transfer, accept, or avoid — with justification;
the treatment plan for the highest-rated risk — what will be done, by whom, by when, and at what cost;
the key risk indicators that would provide early warning of the risks increasing;
the reporting you would provide to the executive and to the board.

Support your assessment with reference to the lesson material and to a published framework (ISO/IEC 27005, NIST SP 800-30, or equivalent).

Activity 2 — Cyber risk quantification

Choose a specific cyber risk scenario for an enterprise — a ransomware incident affecting a defined set of systems, a data breach affecting a defined data category, or a third-party outage affecting a defined service. Conduct a quantitative analysis using the FAIR model (500–600 words):

the scope — the asset or scenario, the threat community, and the loss event being assessed;
threat event frequency — the estimated range, with the basis for the estimate (internal data, industry data, threat intelligence, expert judgement);
vulnerability — the estimated probability of success given the controls in place, with the basis;
primary loss — the estimated range of direct costs, itemised;
secondary loss — the estimated range of consequential costs, itemised;
the resulting annualised loss exposure, expressed as a range with a most likely value;
the probability of exceeding a defined threshold — for example, exceeding the enterprise's stated risk tolerance;
the sensitivity of the result to the key assumptions — which assumptions drive the outcome;
the decision the analysis would inform, and the reservations you would express about its precision.

Support your analysis with reference to the FAIR model and to published cyber loss data where available.

Activity 3 — Preparing for Forum 6 and Assignment 3

Forum 6 addresses cybersecurity governance and resilience, including risk assessment methodologies. Assignment 3 requires a governance framework for a university, including a risk assessment for critical infrastructure — both of which depend directly on the material in this lesson.

Review the Forum 6 prompts and the Assignment 3 brief. Draft the risk management section of your university governance framework — including the framework you would adopt, the risk assessment approach, the register design, the ownership model, and the specific challenges a university presents (decentralised risk ownership, academic freedom, research data, and a large and diverse user population).

15 Self-check

Answer the questions below before moving to Lesson 6.4. If you cannot answer a question confidently, revisit the corresponding section.

16 Summary

This lesson has examined risk management frameworks — the discipline through which an enterprise identifies, assesses, treats, monitors, and reports the cyber risk it carries. The essential points are:

Risk management directs finite resources. Every enterprise has more exposure than it can eliminate. Risk management is how resources are directed toward the exposures that matter most — and how the enterprise understands what it is choosing to live with.
Risk is a function of likelihood and impact. Both dimensions must be considered. Inherent risk is the exposure before controls; residual risk is the exposure after — and the gap between them is the value of the controls.
Risk can be expressed qualitatively, semi-quantitatively, or quantitatively. The method should be proportionate to the decision it informs — qualitative for broad assessment, quantitative where the decision is financial.
Several frameworks structure the discipline. ISO 31000 for general structure; ISO/IEC 27005 for information security; NIST RMF for control-based management; FAIR for quantification; COSO ERM for enterprise integration.
The process is iterative, not linear. Establish context, identify, analyse, evaluate, treat, monitor, and communicate — with monitoring feeding back into identification, and treatment changing the risk that was assessed.
Identification is the step most frequently underdone. The risks that cause the greatest harm are frequently the ones that were not on the list — and deliberate effort to identify what is not obvious is the most valuable part of the exercise.
Risk matrices are a communication tool, not a measurement instrument. They multiply ordinal scales as if cardinal, compress range, produce inconsistent ratings, and cannot be aggregated — but remain useful for prioritisation and communication.
Four treatment options exist. Mitigate, transfer, accept, and avoid — with the objective not to eliminate risk, but to bring it within appetite at an acceptable cost.
Monitoring closes the loop. Key risk indicators, control monitoring, and treatment tracking detect changes — and reporting ensures the people who need to know are informed.
Quantification is valuable when the decision is financial. FAIR decomposes risk into measurable factors and expresses it as an annualised loss distribution — but false precision is more dangerous than honest uncertainty.
The register is a decision-support tool. It should contain what is required to manage and report on risk, with a named individual owner for every material risk — accountable for treatment and acceptance.
Common pitfalls recur. Risk management as a compliance exercise; no appetite to assess against; every risk high; risks never treated or accepted; risks without owners; owners without authority; assessment without monitoring; treatment without verification; false precision; register bloat; aggregation ignored; failure to close risks.

These ideas prepare for the remainder of Unit 6. Lesson 6.4 examines compliance and regulatory requirements — the external obligations that constrain what risk can be accepted. Lesson 6.5 examines awareness and human factors. Lesson 6.6 examines auditing. Lessons 6.7–6.9 examine incident response, business continuity, and cyber resilience — all of which are risk treatments. Lesson 6.10 examines emerging trends.

Before moving on

Make sure you can explain why risk management matters, define the fundamental risk concepts, describe the principal frameworks, apply the risk management process, evaluate identification techniques, compare assessment methods, apply treatment options, design monitoring and reporting, evaluate quantification approaches, and design a risk register and ownership model. If you cannot yet do all eight, revisit Sections 2, 3, 4, 6, 7, 8, 9, and 10.

Next lesson

Lesson 6.4 — Compliance and Regulatory Requirements examines the external obligations that constrain the enterprise's security effort — the privacy, sectoral, cross-sector, and contractual regimes that establish the floor beneath which the enterprise cannot fall.

COMP 6660 · Enterprise Cybersecurity Risk Management Frameworks

00 Introduction

How to read this lesson

01 Learning objectives

Lesson objectives

02 Why risk management matters

It directs finite resources

It connects security to business objectives

It provides the basis for accountability

It informs governance

It is required by regulation and standard

It supports defensible decision-making

What risk management failure looks like

The defining characteristic

03 Risk fundamentals

The core concepts

The risk equation

Inherent and residual risk

Qualitative, semi-quantitative, and quantitative risk

The most useful framing

04 Risk management frameworks

The principal frameworks

ISO 31000 — the general framework

ISO/IEC 27005 — information security risk management

NIST Risk Management Framework

FAIR — quantitative risk analysis

COSO ERM — enterprise risk management

Selecting and combining frameworks

The most useful framing

05 The risk management process

The process

Iteration and continuous operation

Risk assessment at different levels

The most useful framing

06 Risk identification

Approaches to identification

Sources of risk information

Structuring identified risks

Common failures in identification

The most consequential identification failure

07 Risk assessment and analysis

Assessing likelihood

Assessing impact

Assessing control effectiveness

Qualitative assessment methods

Weaknesses of risk matrices

Semi-quantitative approaches

The most useful framing

08 Risk evaluation and treatment

Risk evaluation

Risk treatment options

Selecting treatments

Treatment planning

Treatment in practice

The most useful framing

09 Risk monitoring and reporting

What to monitor

Key risk indicators

Risk reporting

Board risk reporting

Monitoring and the risk management cycle

The most useful framing

10 Cyber risk quantification

Why quantification matters

The FAIR model in detail

Conducting a FAIR analysis

Obtaining data

Limitations of quantification

Using quantification appropriately

The most consequential quantification failure

11 Risk registers and risk ownership

What a risk register is

Register content

Risk ownership

Common ownership failures

The register as a management tool

Register hygiene

The most useful framing

12 Common pitfalls

Pitfall 1 — Risk management as a compliance exercise