Table of Contents

1.1 What is Risk?

Risk is one of the most fundamental concepts in management, yet it is often poorly defined or misunderstood. In everyday language, 'risk' is frequently used as a synonym for 'danger' or 'hazard.' However, in a professional risk management context, the definition is far more precise and nuanced.

The ISO 31000:2018 standard defines risk as:

1.1.1 Unpacking the Definition

This definition has three critical components that must be understood:

• Effect: A risk is not the event itself — it is the impact that uncertainty has on your ability to achieve objectives. Effects can be positive (opportunities) or negative (threats).
• Uncertainty: Risk arises from a lack of complete knowledge about future events. This includes uncertainty about whether an event will occur, when it will occur, or what its consequences will be.
• Objectives: Risk is always relative to something. Without defined objectives, you cannot define risk. A storm is only a risk if you have an objective that the storm might affect (e.g., completing a construction project on time).

1.1.2 Risk vs Uncertainty vs Hazard

1.2 The ISO 31000:2018 Framework Overview

ISO 31000:2018 is the international standard for risk management. It was first published in 2009 and significantly revised in 2018 to reflect evolving best practice. The standard provides principles, a framework, and a process that organisations can adopt and adapt.

ISO 31000 is deliberately non-prescriptive — it does not provide a single 'correct' method. Instead, it establishes a consistent set of principles that can be applied across any organisation, industry, or sector.

1.2.1 The Three Pillars of ISO 31000

• Principles: Eight principles that describe the characteristics of effective risk management
• Framework: The organisational infrastructure needed to support risk management (leadership, integration, design, implementation, evaluation, improvement)
• Process: The operational steps for assessing and treating risk (communication, context, assessment, treatment, monitoring, recording)

1.2.2 The Eight Principles of ISO 31000:2018

ISO 31000 states that risk management should be:

1. Integrated — embedded in all organisational activities, not a standalone process
2. Structured and comprehensive — producing consistent, comparable, and reliable results
3. Customised — tailored to the organisation's context and objectives
4. Inclusive — appropriately involving stakeholders at all levels
5. Dynamic — responsive to changing context and events
6. Best available information — based on historical data, expert judgement, stakeholder feedback, and observation
7. Human and cultural factors — acknowledging that human behaviour shapes risk and its management
8. Continual improvement — learning and improving over time

1.3 Types of Risk

Organisations face risk across many dimensions. The following taxonomy is widely used in enterprise risk management:

1.4 The Risk Management Lifecycle

Risk management is not a one-time event — it is a continuous cycle. The lifecycle model reflects the iterative nature of effective risk management:

• Establish context: Define the organisation's objectives, environment, and risk criteria
• Identify risks: Systematically surface risks that could affect objectives
• Analyse risks: Understand the nature, likelihood, and consequences of risks
• Evaluate risks: Prioritise risks against criteria and determine treatment priorities
• Treat risks: Implement controls and responses to modify risk
• Monitor and review: Continuously check the effectiveness of controls and the changing risk landscape
• Communicate and consult: Engage stakeholders throughout the entire process

1.5 Why Risk Management Matters

Effective risk management delivers organisational value in multiple ways:

• Improved decision making — leaders make better decisions when they understand the risks involved
• Resource optimisation — focus resources on the most significant risks rather than all risks equally
• Regulatory compliance — many industries require formal risk management frameworks
• Stakeholder confidence — investors, regulators, and customers expect to see evidence of mature risk management
• Organisational resilience — organisations with strong risk management recover faster from adverse events
• Competitive advantage — proactive risk management can reveal opportunities others miss

2.1 Overview of the Process

The ISO 31000 risk management process is the operational core of the standard. It provides a structured approach to identifying, analysing, evaluating, and treating risk. The process is not linear — it is iterative, and communication and consultation run through all stages.

The process components are:

1. Communication and consultation
2. Scope, context, and criteria
3. Risk assessment (identification, analysis, evaluation)
4. Risk treatment
5. Monitoring and review
6. Recording and reporting

2.2 Communication and Consultation

Communication and consultation are not a step that happens once — they are continuous activities that run throughout the entire risk management process. This component ensures that all relevant stakeholders are informed, engaged, and able to contribute.

2.2.1 Why It Matters

Poor communication is one of the most common causes of risk management failure. If risk owners do not understand their responsibilities, or if leadership does not receive timely risk information, the entire framework breaks down.

2.2.2 What It Involves

• Identifying stakeholders — who has an interest in, or influence over, risk decisions?
• Designing communication plans — what information does each stakeholder need, in what format, and how often?
• Consultation mechanisms — how will you gather input from stakeholders during risk identification and evaluation?
• Escalation pathways — how will significant risks be escalated to leadership?
• Reporting frameworks — how will risk information be reported to governance bodies?

2.3 Scope, Context, and Criteria

Before any risk can be assessed, you must define the boundaries and context of the assessment. This is often the most undervalued step in the process, yet it fundamentally shapes everything that follows.

2.3.1 Defining Scope

• What objectives are we assessing risks against?
• What time horizon applies?
• What organisational units, processes, or projects are included?
• What is explicitly excluded from this assessment?

2.3.2 External Context

External context includes factors outside the organisation that could influence risk:

• Political, economic, social, technological, environmental, and legal (PESTLE) factors
• Market conditions and competitive environment
• Regulatory and legislative requirements
• Relationships with external stakeholders (suppliers, customers, regulators, community)

2.3.3 Internal Context

Internal context includes factors within the organisation:

• Organisational structure, roles, and governance
• Culture, values, and risk appetite
• Strategies, objectives, and policies
• Capabilities (resources, knowledge, technology)
• Contractual relationships and obligations

2.3.4 Establishing Risk Criteria

Risk criteria are the benchmarks against which the significance of a risk is evaluated. Criteria should be set before assessment begins — not after — to avoid bias. Criteria typically address:

• The nature and type of consequences that matter
• How likelihood is defined and measured
• How consequence and likelihood are combined into a risk level
• Threshold levels that determine when a risk requires treatment
• Risk appetite statements (how much risk the organisation is willing to accept)

2.4 Risk Assessment

2.5 Risk Treatment

Risk treatment involves selecting and implementing options to modify risk. The treatment process includes:

• Generating treatment options
• Evaluating options (feasibility, cost, effectiveness)
• Selecting and planning treatment actions
• Implementing treatments
• Assessing residual risk after treatment
• Deciding whether residual risk is acceptable

2.6 Monitoring and Review

2.6.1 What to Monitor

• The external and internal context (has anything changed that affects risk?)
• The risk landscape (have new risks emerged? Have existing risks changed?)
• The effectiveness of controls and treatments
• Key risk indicators (KRIs) that provide early warning signals
• Compliance with risk management policies and procedures

2.6.2 Review Frequency

2.7 Recording and Reporting

ISO 31000 emphasises that risk management activities and outcomes should be documented. Recording and reporting serves multiple purposes:

• Accountability — creates a record of decisions and their rationale
• Learning — enables analysis of past decisions and outcomes to improve future practice
• Compliance — many regulatory frameworks require evidence of risk management activities
• Governance — boards and senior leadership require risk information to fulfil their oversight responsibilities
• Stakeholder confidence — transparent risk reporting builds trust with investors, regulators, and the public

3.1 The Purpose of Risk Identification

Risk identification is the first step in the risk assessment process. Its purpose is to find, recognise, and describe risks that might affect the achievement of objectives. The goal is comprehensiveness — you cannot manage a risk you have not identified.

ISO 31000 notes that risk identification should consider both internal and external sources of risk, and should look at risks that are certain, possible, or merely conceivable. Uncertainty about risk sources is itself a risk.

3.2 Brainstorming and Structured Interviews

3.2.1 Brainstorming

Brainstorming is the most widely used risk identification technique. It involves gathering a group of knowledgeable individuals and generating risks through open, creative discussion.

How to Run a Risk Brainstorm

1. Define the objective: What are you assessing risks against? Be specific.
2. Assemble the right group: Include people with diverse perspectives and expertise.
3. Brief participants: Explain the process and the definition of risk being used.
4. Generate ideas: Use open questions — 'What could prevent us achieving this?' 'What could go wrong?' 'What could we be missing?'
5. Capture all ideas: Do not evaluate or dismiss ideas during generation.
6. Categorise and consolidate: Group similar risks and eliminate duplicates.
7. Prioritise for further analysis: Agree on which risks warrant deeper analysis.

Strengths and Limitations

3.2.2 Structured Interviews

Structured interviews involve one-on-one conversations with subject matter experts, using a prepared set of questions. They are particularly useful when:

• Sensitive topics make group discussion difficult
• Specialists hold knowledge not shared by the broader group
• Participants are geographically dispersed
• An independent view is needed to validate group-based findings

Interview Design Tips

• Use open-ended questions ('What concerns you most about...?')
• Probe for specifics ('Can you give me an example of when that happened?')
• Ask about past near-misses and incidents
• Ask about changes: 'What has changed recently that might create new risks?'
• Use a standard interview guide to ensure consistency across interviews

3.3 SWOT and PESTLE Analysis

3.3.1 SWOT Analysis

SWOT (Strengths, Weaknesses, Opportunities, Threats) is a strategic planning tool that can be adapted for risk identification. In a risk context:

• Weaknesses surface potential internal risk sources
• Threats identify external risks
• Strengths and Opportunities help identify controls and risk responses already in place

SWOT is most useful at a strategic level — for identifying risks to organisational or project objectives. It is less useful for granular operational risk identification.

3.3.2 PESTLE Analysis

3.4 Bow-Tie Analysis

Bow-tie analysis is a powerful visual technique that maps both the causes of a risk event and its consequences. It gets its name from the shape of the diagram — two triangles meeting at a central event node, resembling a bow tie.

3.4.1 Structure of a Bow-Tie

• Left side (Threat Tree): The causes or threat pathways that could lead to the central risk event
• Central node: The top event or hazard being analysed
• Right side (Consequence Tree): The potential consequences that flow from the event
• Barriers: Controls placed on the left (preventive) and right (mitigative) sides of the diagram

3.4.2 When to Use Bow-Tie Analysis

• Analysing major risks with multiple potential causes and consequences
• Communicating risk to non-technical stakeholders (the visual format is highly intuitive)
• Evaluating the adequacy of existing controls
• Planning risk treatment — it clearly shows where additional barriers are needed

3.4.3 Strengths and Limitations

• Strength: Provides a complete causal picture of a risk — both prevention and recovery
• Strength: Highly visual and accessible to non-specialists
• Limitation: Can become very complex for risks with many causes or consequences
• Limitation: Does not quantify likelihood — typically qualitative

3.5 Checklists and Prompt Lists

Checklists are pre-compiled lists of potential risk sources, developed from past experience, industry knowledge, or regulatory requirements. They ensure that common risks are not overlooked.

3.5.1 Types of Checklists

• Industry-specific checklists (e.g., construction risk checklists, healthcare risk prompts)
• Regulatory checklists (risks associated with compliance with specific legislation)
• Project risk checklists (common risks in project delivery)
• IT/cyber checklists (mapped to frameworks like NIST CSF or ISO 27001)

3.5.2 Limitations of Checklists

Checklists are a useful supplement to, not a substitute for, other identification methods. They have two significant weaknesses:

• They only capture known risks — by definition, they cannot surface novel or emerging risks
• They can create a false sense of completeness — if a risk is not on the list, it may be overlooked

3.6 Process Mapping and Cause-and-Effect Diagrams

3.6.1 Process Mapping

Process mapping (or value stream mapping) identifies risks by systematically walking through each step in a business process and asking: 'What could go wrong here?' For each process step, consider:

• What inputs are required? What if they are late, incorrect, or unavailable?
• Who performs the task? What if they are unavailable, untrained, or make an error?
• What systems or equipment are used? What if they fail?
• What are the handoff points? Where could information be lost or distorted?

3.6.2 Cause-and-Effect (Ishikawa / Fishbone) Diagrams

The Ishikawa diagram (also known as the fishbone or cause-and-effect diagram) is a structured technique for identifying the root causes of a specific risk event or problem. The 'head' of the fish is the effect (the risk event), and the 'bones' represent categories of causes.

The classic 6M categories are: Methods, Machines, Materials, Measurement, Man (people), and Mother Nature (environment). These can be adapted for any context.

3.7 Failure Mode and Effects Analysis (FMEA)

FMEA is a systematic, bottom-up technique originally developed for engineering and manufacturing but now widely applied in risk management. It examines each component of a system and asks: 'How could this fail, and what would the effect be?'

3.7.1 The FMEA Process

1. List all components, process steps, or functions
2. For each, identify all potential failure modes (ways it could fail)
3. For each failure mode, identify the effects (consequences)
4. Rate severity (S), likelihood/occurrence (O), and detectability (D) on scales of 1–10
5. Calculate the Risk Priority Number: RPN = S × O × D
6. Prioritise high-RPN failures for corrective action

4.1 The Purpose of Risk Analysis

Once risks have been identified, the next step is to understand their nature and significance. Risk analysis involves developing an understanding of each risk — its sources, causes, likelihood, and potential consequences. This understanding provides the basis for risk evaluation and treatment decisions.

ISO 31000 distinguishes between qualitative, semi-quantitative, and quantitative analysis. This module focuses on qualitative methods — the most widely used approach in enterprise risk management.

4.2 Qualitative Risk Analysis Fundamentals

Qualitative analysis uses descriptive scales (words or categories) rather than numbers to rate risk likelihood and consequence. It is faster and less data-intensive than quantitative methods, making it practical for most enterprise risk assessments.

4.2.1 Likelihood Scales

4.2.2 Consequence Scales

4.3 The Risk Rating Matrix

A risk rating matrix (also called a risk matrix or risk assessment matrix) is a grid that combines likelihood and consequence ratings to produce an overall risk level. It is the most common tool in qualitative risk assessment.

4.3.1 How the Matrix Works

The matrix plots likelihood on one axis and consequence on the other. For a 5×5 matrix, scores range from 1 (1×1) to 25 (5×5). Scores are then grouped into risk bands:

4.3.2 Variations in Matrix Design

• 4×4 Matrix: Used where fewer rating levels are preferred for simplicity
• 5×5 Matrix: The most common — provides good discrimination between risk levels
• Asymmetric matrices: Where the weight given to consequence vs likelihood is adjusted
• Multi-dimensional matrices: Where separate scores are calculated for financial, safety, and reputational impact

4.3.3 Limitations of Risk Matrices

• False precision — a '3' likelihood rating may mean different things to different assessors
• Aggregation issues — multiplying likelihood by consequence can misrepresent true risk
• Poor handling of tail risks — rare but catastrophic events often appear 'low' because of their low likelihood
• Cognitive biases — assessors may anchor to prior assessments or be influenced by recent events

4.4 Heat Maps

A heat map is a visual representation of risk data from a risk matrix. Each risk is plotted as a point (or bubble) on the matrix grid, with colour coding to indicate risk level.

4.4.1 Types of Heat Maps

• Point heat maps: Each risk is plotted as a single point
• Bubble heat maps: Bubble size represents an additional variable (e.g., number of risks in that cell, or financial exposure)
• Before/after heat maps: Show risk positions before and after treatment
• Velocity maps: Incorporate a third dimension — the speed at which a risk could escalate

4.5 Inherent vs Residual Risk

4.6 Worked Example — Qualitative Risk Analysis

5.1 When to Use Quantitative Methods

Qualitative analysis is appropriate for most enterprise risk assessments. However, there are situations where more rigorous, numerical approaches are warranted:

• High-stakes decisions requiring precise risk-cost trade-offs
• Regulatory requirements (e.g., financial sector capital adequacy models)
• Risks with sufficient historical data to support statistical modelling
• Large-scale projects where risk quantification informs contingency budgets
• Insurance and risk transfer decisions where precise probability estimates are needed

5.2 Semi-Quantitative Methods

5.2.1 Weighted Scoring Systems

In weighted scoring, numerical weights are assigned to risk dimensions. For example:

• Likelihood is scored 1–5, multiplied by a weight of 0.4
• Financial consequence is scored 1–5, multiplied by a weight of 0.3
• Reputational consequence is scored 1–5, multiplied by a weight of 0.2
• Safety consequence is scored 1–5, multiplied by a weight of 0.1

5.2.2 Risk Priority Numbers (RPN)

As introduced in Module 3, FMEA uses RPN = Severity × Occurrence × Detectability. Each factor is scored 1–10, giving RPNs from 1 to 1,000. While this produces numbers, the inputs are still qualitative judgements — making FMEA a semi-quantitative method.

5.3 Probability and Impact Modelling

5.3.1 Expected Value

The simplest quantitative risk measure is expected value (EV):

Example: If there is a 20% probability of a project cost overrun of $500,000, the expected value of that risk is 0.20 × $500,000 = $100,000. This $100,000 should be included in the project contingency budget.

5.3.2 Probability Distributions

• Normal distribution: Symmetric, bell-shaped. Used for risks with naturally symmetric variation (e.g., measurement error).
• Triangular distribution: Defined by minimum, most likely, and maximum values. Useful when expert estimates provide these three points.
• Lognormal distribution: Used for risks that are bounded at zero (cannot be negative) and positively skewed — common in financial loss modelling.
• PERT distribution: A smoothed version of the triangular, placing more weight on the most likely value. Widely used in project risk analysis.

5.4 Monte Carlo Simulation

Monte Carlo simulation is a quantitative technique that models risk by running thousands of iterations of a model, each time sampling from probability distributions assigned to uncertain variables.

5.4.1 How Monte Carlo Works

1. Define the model: Identify the key variables and their relationships.
2. Assign probability distributions: For each uncertain variable, define a distribution.
3. Run iterations: The software randomly samples from each distribution and calculates the outcome — repeated thousands of times (typically 10,000+).
4. Analyse results: The output is a distribution of possible outcomes. You can read off the probability of achieving any given outcome.

5.4.2 Practical Application

Monte Carlo is most commonly used for:

• Project schedule and cost risk analysis (Earned Value Management, project contingency setting)
• Financial modelling (revenue forecasting under uncertainty, investment risk analysis)
• Insurance and catastrophe modelling
• Supply chain risk quantification

5.4.3 Limitations

• Results are only as good as the input distributions — poor estimates in, poor estimates out
• Requires specialist software (e.g., @Risk, Crystal Ball, Oracle Primavera Risk Analysis)
• Can create false confidence in results if stakeholders don't understand the model's assumptions

5.5 Value at Risk (VaR)

5.5.1 Limitations of VaR

• It says nothing about what happens in the 5% tail — the severity of tail losses is not captured
• Historical VaR models assume the future resembles the past — they can fail badly in unprecedented events (the 2008 financial crisis exposed this weakness)
• VaR can create perverse incentives — traders can game VaR limits by taking positions with low probability but catastrophic tail losses

5.6 When to Use Qualitative vs Quantitative Analysis

6.1 The Purpose of Risk Evaluation

Risk evaluation is the process of comparing the results of risk analysis against risk criteria to determine which risks require treatment and in what priority order. It is the bridge between analysis and action.

ISO 31000 emphasises that risk evaluation involves value judgements — it is not a purely technical exercise. Decisions about what level of risk is acceptable involve ethical, social, and organisational values, not just numbers.

6.2 Setting Risk Criteria and Appetite

6.2.1 Risk Criteria

• The nature and type of consequences that matter (safety, financial, reputational, environmental, etc.)
• How likelihood is measured and what timeframe applies
• How consequence and likelihood combine to produce a risk level
• What risk levels are acceptable, tolerable, or intolerable
• The level at which risks must be escalated or formally treated

6.2.2 Risk Appetite

6.3 Comparing Risk Levels Against Criteria

• Risk is within appetite / acceptable: No treatment required. Monitor and review.
• Risk is above appetite but tolerable: Treatment is required to reduce to an acceptable level. Prioritise according to urgency and severity.
• Risk is intolerable / extreme: Immediate action required. Cannot be accepted under any circumstances until treated.

6.4 The ALARP Principle

ALARP stands for 'As Low As Reasonably Practicable.' It is a principle originating in UK health and safety law but now widely applied in risk management across many sectors. ALARP establishes three risk zones:

• Unacceptable region: Risk is so high that it cannot be justified under any circumstances. Must be eliminated or reduced regardless of cost.
• ALARP / Tolerable region: Risk is tolerable only if its reduction is impracticable or if the cost of reduction is grossly disproportionate to the benefit gained.
• Broadly acceptable region: Risk level is so low that it is not worth spending resources to reduce it further.

6.4.1 Demonstrating ALARP

• Document all available control options
• Conduct cost-benefit analysis for each option
• Show that options with costs grossly disproportionate to benefits have been appropriately considered
• Implement all practicable controls
• Maintain records demonstrating the ALARP case

6.5 Prioritising Risks for Treatment

• Risk score: Higher-scoring risks generally take priority
• Velocity: How quickly could a risk escalate?
• Control strength: Risks with weak or absent controls may require faster treatment
• Strategic impact: Risks threatening core strategic objectives take priority
• Regulatory obligation: Some risks must be treated to meet legal requirements
• Treatment effectiveness: Some high-priority risks may have highly effective, low-cost treatments — quick wins

6.6 Communicating Evaluation Results to Stakeholders

• Tailor the message to the audience — board members need strategic summaries; operational managers need detailed specifics
• Lead with the most significant risks — don't bury the key message in data
• Provide context — explain what the risk means in practical terms, not just as a score
• Include treatment status — don't just report the problem; show what is being done
• Use visual tools — heat maps, trend charts, and dashboards make risk data more accessible
• Be honest about uncertainty — acknowledge where assessment is based on limited data or expert judgement

7.1 The Purpose of Risk Treatment

Risk treatment is the process of selecting and implementing options to modify risk. Note the word 'modify' — risk treatment does not always mean risk reduction. Depending on the risk and the organisation's objectives, treatment may involve increasing a risk (to capture an opportunity), reducing a risk, or transferring it.

7.2 The Five Treatment Options

7.3 Developing Risk Treatment Plans

A risk treatment plan should specify:

• What actions will be taken (specific, not vague)
• Who is responsible for each action (named individual, not just a role)
• When each action will be completed (specific date, not 'as soon as possible')
• What resources are required
• How the effectiveness of the treatment will be measured
• What the expected residual risk level will be after treatment

7.4 Cost-Benefit Analysis of Controls

7.4.1 Calculating the Benefit of a Control

7.4.2 Factors Beyond Financial Cost

• Regulatory compliance requirements — some controls are mandatory regardless of cost
• Reputational and trust impacts — some risks have consequences beyond financial loss
• Employee wellbeing — safety controls may be justified on ethical grounds beyond financial analysis
• Strategic value — controls that also deliver business value

7.5 Residual Risk Assessment

After treatments are implemented, the residual risk must be reassessed. The key questions are:

• Has the treatment reduced risk to within the organisation's risk appetite?
• Have any new risks been introduced by the treatment itself? (Treatment risk)
• Are there any dependencies on the treatment that create new vulnerabilities?
• Is the residual risk acceptable, or does it require further treatment?

7.6 Treatment Monitoring and Effectiveness Review

Ongoing monitoring is required to confirm that:

• The treatment has been fully implemented as planned
• The treatment is having the expected effect on risk levels
• No unintended consequences have arisen from the treatment
• The underlying risk has not changed in ways that make the treatment obsolete

8.1 Enterprise / Organisational Risk

Enterprise Risk Management (ERM) applies risk assessment at the highest level of an organisation — integrated with strategic planning and governance. Key features of ERM include:

• Alignment of the risk framework with the organisation's strategic objectives
• Board-level ownership and oversight of the risk program
• An enterprise-wide risk register covering strategic, operational, financial, and compliance risks
• Integration of risk management into decision-making processes (capital allocation, strategic planning, acquisitions)
• Key risk indicators linked to strategic KPIs

8.1.1 Common ERM Frameworks

8.2 Project Risk Management

Projects are inherently risky — they involve unique undertakings with uncertain outcomes, often under time and budget pressure.

8.2.1 The Project Risk Register

Every project should maintain a risk register from inception through closeout. The register should be reviewed at key project milestones: project initiation, each phase gate, and monthly throughout delivery.

8.2.2 Project-Specific Risk Techniques

• Schedule Risk Analysis (Monte Carlo on project timelines)
• Cost Risk Analysis (probability-based contingency estimation)
• Assumption and Dependency Logs (identifying risks embedded in project assumptions)
• RAID Logs (Risks, Assumptions, Issues, Dependencies)
• Earned Value Management (EVM) for tracking project performance against risk

8.2.3 ISO 31000 and PMI/PRINCE2

ISO 31000 is compatible with project management frameworks such as PMBoK (Project Management Body of Knowledge) and PRINCE2. The ISO 31000 process maps closely to the risk management knowledge area in PMBoK and the risk theme in PRINCE2.

8.3 Supply Chain and Third-Party Risk

8.3.1 Key Third-Party Risk Categories

• Operational/delivery risk: Supplier inability to deliver on time or to specification
• Financial risk: Supplier insolvency or financial instability
• Compliance risk: Supplier non-compliance with legal or ethical standards (modern slavery, anti-bribery, environmental)
• Cybersecurity / data risk: Supplier access to sensitive data or systems
• Concentration risk: Over-dependence on a single supplier or geographic region
• Reputational risk: Adverse media coverage of a supplier reflecting on your organisation

8.3.2 Third-Party Risk Assessment Approach

1. Maintain a supplier inventory with risk tiering (critical, important, standard)
2. Apply due diligence proportional to risk tier
3. Include risk management requirements in supplier contracts
4. Monitor supplier performance and risk indicators on an ongoing basis
5. Have contingency plans for key supplier failures

8.4 IT and Cybersecurity Risk

8.4.1 Key Cybersecurity Risk Frameworks

8.4.2 Cyber Risk Assessment Approach

• Asset inventory: You cannot protect what you don't know you have
• Threat identification: What threat actors are relevant? What are their capabilities and motivations?
• Vulnerability assessment: What weaknesses exist in systems, processes, and people?
• Impact analysis: What would be the consequence of a successful attack?
• Control assessment: What controls are in place, and how effective are they?
• Residual risk determination and treatment planning

8.5 Health, Safety, and Environment (HSE) Risk

8.5.1 Safety Case Approach

The safety case is a structured argument, supported by evidence, that a system or operation is safe for a given context. Safety cases are required in high-hazard industries (aviation, nuclear, offshore oil and gas, rail). They demonstrate that:

• All hazards have been identified
• Risk from each hazard is As Low As Reasonably Practicable (ALARP)
• Adequate barriers and controls are in place
• A culture of continuous safety improvement exists

8.5.2 Environmental Risk

Environmental risk assessment applies risk techniques to potential environmental harm. ISO 14001 (Environmental Management Systems) is the relevant standard and is complementary to ISO 31000. Key environmental risk assessment techniques include Environmental Impact Assessment (EIA), lifecycle assessment, and chemical risk assessment.

9.1 The Risk Register

The risk register is the central document in an organisation's risk management program. It is a living record of all identified risks, their assessment, treatment status, and ownership. Well-designed risk registers are practical, accessible tools — not bureaucratic documents that gather dust.

9.2 Designing a Risk Register

9.3 Key Risk Indicators (KRIs)

Key Risk Indicators (KRIs) are metrics that provide early warning of increasing risk exposure. They function as the risk management equivalent of warning lights on a dashboard — they don't tell you the engine has failed, they tell you it's getting hot.

9.3.1 Characteristics of Good KRIs

• Predictive: They give advance warning of a risk event, not just measure it after it occurs
• Measurable: They can be objectively measured, not just estimated
• Timely: They can be measured frequently enough to be useful
• Linked to risk: They have a clear, logical connection to the risk they are monitoring
• Actionable: When a KRI threshold is breached, it is clear what action should be taken

9.3.2 KRI Thresholds

9.3.3 KRI Examples

9.4 Escalation and Reporting Frameworks

9.4.1 Escalation Pathways

• Operational-level risks (Low/Medium): Managed by the risk owner. Reported in operational reviews.
• Divisional-level risks (Medium/High): Reported to divisional management. Included in divisional risk reviews.
• Enterprise-level risks (High/Extreme): Reported to the Chief Risk Officer or equivalent. Included in executive risk reports.
• Board-level risks (Extreme/Strategic): Reported to the board or audit and risk committee. Board approval required for treatment plans.

9.4.2 Risk Reporting Hierarchy

1. Frontline risk owners: Maintain and update individual risk entries in the register
2. Risk champions / divisional managers: Review and consolidate risks for their division
3. Risk management function: Aggregate and analyse the enterprise risk register; prepare management reports
4. Executive leadership: Review enterprise risk report; approve treatment plans for high/extreme risks
5. Audit and risk committee: Oversight of the enterprise risk framework; review of top risks
6. Board: Governance oversight; approval of risk appetite; review of strategic risks

9.5 Board-Level Risk Reporting

Board-level risk reports should be:

• Concise — boards are time-constrained; the report should be readable in under 30 minutes
• Focused on the top risks — typically the top 5–15 risks by residual risk score
• Forward-looking — not just describing current risks but emerging risks and trends
• Actionable — clearly stating what decisions the board needs to make
• Visual — using heat maps, trend charts, and risk movement indicators
• Honest — boards need to know about bad news early, not when it's too late to act

9.6 Integrating Risk Reporting with GRC

Governance, Risk, and Compliance (GRC) is an integrated approach to managing these three related disciplines. GRC platforms integrate risk registers with compliance tracking, audit management, and governance workflows. Key integration benefits include:

• Single source of truth for risk and compliance information
• Automated workflow for risk assessments, approvals, and escalations
• Real-time dashboards and reporting
• Evidence management for audits and regulatory reviews
• Cross-referencing of risks with controls and compliance obligations

10.1 Why Culture is the Foundation of Risk Management

Technical frameworks, sophisticated software, and detailed procedures are only as effective as the culture in which they operate. An organisation with excellent risk management tools but a poor risk culture will consistently underperform in risk management. Conversely, an organisation with a strong risk culture can manage risk effectively even with relatively simple tools.

10.2 Leadership and Accountability

The tone at the top is the single most important determinant of risk culture. When leaders treat risk management as a compliance exercise, so will their people. When leaders demonstrate genuine engagement with risk — asking good questions, making risk-informed decisions, and holding people accountable — the culture follows.

10.2.1 Leadership Behaviours That Build Risk Culture

• Regularly discussing risk at executive and board meetings
• Asking probing questions about risk when reviewing proposals and strategies
• Celebrating risk identification — not just risk avoidance
• Creating psychological safety for people to raise concerns without fear of blame
• Taking swift, visible action on critical risks
• Modelling the risk management behaviours expected of others

10.2.2 Risk Ownership and Accountability

Every risk in the risk register should have a named owner — a specific individual who is accountable for managing and monitoring that risk. Risk ownership accountability requires:

• Clear understanding of ownership responsibilities (not just being 'named' in a register)
• Regular reporting on risk status by owners
• Consequences for failing to manage risks appropriately
• Recognition for effective risk management

10.3 Embedding Risk Management in Decision-Making

10.4 Training and Communication Strategies

10.4.1 Training

Effective risk management training should be:

• Role-appropriate: Frontline staff need different training from executives.
• Practical: Focused on the risk tools and processes people will actually use in their role
• Regular: Not a one-off induction activity, but ongoing development
• Blended: Combining formal training with on-the-job coaching and peer learning

10.4.2 Communication

• Use plain language — avoid jargon and technical terminology where possible
• Be transparent about uncertainty — acknowledge what is not known
• Focus on decisions — what does this risk information mean for the decisions we need to make?
• Be two-way — encourage questions and challenge
• Be appropriately timed — risk information is most valuable when it is timely and actionable

10.5 Continuous Improvement of the Risk Framework

10.5.1 Framework Review Questions

• Is the risk management process being followed consistently?
• Are risks being identified comprehensively?
• Is the risk assessment methodology producing reliable, consistent results?
• Are treatment plans being implemented effectively?
• Is the risk register being maintained and updated regularly?
• Are risk reports reaching the right people at the right time?
• Has the external or internal context changed in ways that require framework updates?
• Are stakeholders satisfied with the risk management process?

10.5.2 Learning from Incidents and Near-Misses

Every incident, near-miss, or unexpected risk event is a learning opportunity. Post-incident review should ask:

• Was this risk on the register? If not, why not?
• Were the likelihood and consequence ratings accurate?
• Did the controls in place perform as expected?
• Was the incident detected early enough? If not, why not?
• What changes to the risk framework are indicated?

10.6 ISO 31000 Audit Considerations

While ISO 31000 is not a certifiable standard for organisations, the risk framework may be subject to internal or external audit. Auditors will typically assess:

• Whether a documented risk management framework exists and is appropriate for the organisation
• Whether risk assessments are being conducted and documented in accordance with the framework
• Whether risk registers are current, comprehensive, and being actively managed
• Whether treatment plans are being implemented and their effectiveness monitored
• Whether risk reporting is reaching appropriate governance levels in a timely manner
• Whether the risk management framework is subject to periodic review and improvement

Assessment Overview

This Certificate program uses a combination of assessment methods to test both theoretical knowledge and practical application of risk assessment techniques. All assessments are designed to reflect real-world risk management practice.