8.3 Risk: Threats & Opportunities

PRINCE2 Practitioner Version 7

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Exam Strategy & Open-Book Technique

2 PRINCE2 7 Method Overview

2.1 The PRINCE2 7 Method 2.2 What Changed in PRINCE2 7 2.3 Performance Targets, Tolerances & Project Context

3 PRINCE2 Principles (1–4)

3.1 Continued Business Justification 3.2 Learn from Experience 3.3 Defined Roles, Responsibilities & Relationships 3.4 Manage by Stages

4 PRINCE2 Principles (5–7) & Applying Principles

4.1 Manage by Exception 4.2 Focus on Products 4.3 Tailor to Suit the Project 4.4 Applying Principles in Context

5 People Management in Projects

5.1 Organisational & Project Ecosystems 5.2 Leadership in Projects 5.3 Team Culture & Diversity 5.4 Communication, Stakeholder Engagement & Change Management

6 Practices Overview & Business Case

6.1 The Seven Practices & Tailoring 6.2 Business Case: Desirability, Viability & Achievability 6.3 Business Case Lifecycle & Management Products 6.4 Business Case Application & Tailoring Scenarios

7 Practices: Organising & Plans

7.1 Organising: Roles & Accountability 7.2 Organising: 5-Step Ecosystem Technique 7.3 Plans: Three Levels & Product-Based Planning 7.4 Plans: Techniques, Tolerances & Tailoring

8 Practices: Quality & Risk

8.1 Quality: Planning, Control & Assurance 8.2 Quality Techniques & Management Products 8.3 Risk: Threats & Opportunities 8.4 Risk 5-Step Technique & Application

9 Practices: Issues

9.1 Issues Practice: Issue vs Change & Categories 9.2 Issues 5-Step Technique & Supporting Techniques 9.3 Change Control, Configuration & Priority/Effort Assessment

10 Practices: Progress, Sustainability & Application

10.1 Progress: Controls, Tolerances & Reports 10.2 Sustainability as the 7th Performance Target 10.3 Tailoring the Practices 10.4 Practices Application Scenarios (BL4)

11 Processes: Model, Starting, Directing & Initiating

11.1 The Seven Processes & Process Model 11.2 Starting Up a Project 11.3 Directing a Project 11.4 Initiating a Project

12 Processes: Controlling a Stage & Product Delivery

12.1 Controlling a Stage 12.2 Managing Product Delivery 12.3 Stage Control & Exception Scenarios (BL4) 12.4 Work Packages & Reporting Cycle

13 Processes: Stage Boundary, Closing & Tailoring

13.1 Managing a Stage Boundary 13.2 Closing a Project 13.3 Tailoring the Processes 13.4 Process Application Scenarios (BL4)

14 Tailoring, Management Products & Exam Technique

14.1 Tailoring to Project Environment, Scale & Agile 14.2 Management Products & the v7 Project Log 14.3 Final Exam Technique, Full Scenarios & Common Traps

8.3 Risk: Threats & Opportunities

Key Takeaways Explain This Topic AI

The Risk practice identifies, assesses, and controls uncertainties that could affect project objectives; PRINCE2 v7 treats both threats (negative) and opportunities (positive) as first-class risks.

A risk is decomposed into cause (the source of uncertainty), risk event (the threat or opportunity itself), and effect (the impact on objectives) — this decomposition is central to scenario analysis.

The Risk Management Approach (in the PID) defines how risk is managed, including categories, tolerance, roles, and reporting; the Project Board approves it and the PM produces it.

Risk is evaluated using probability × impact, alongside proximity and tolerance; a risk budget funds agreed responses, distinct from a general contingency.

Last updated: August 2026

Risk Is Two-Sided

A persistent beginner's misconception is that 'risk' means 'bad thing that might happen'. PRINCE2 v7 is explicit that risk is two-sided : a threat is an uncertain event that, if it occurs, would have a negative impact on objectives, while an opportunity is an uncertain event that, if it occurs, would have a positive impact. Both are risks because both arise from uncertainty and both affect whether the project meets its objectives. A scenario that asks you to identify whether a described uncertainty is a threat or an opportunity is testing this single concept.

Treating opportunities as risks is not a theoretical nicety. A project that only plans for threats will systematically miss the upside — the chance to deliver early, to reduce scope cost-effectively, or to capture additional value. The Risk practice therefore applies the same discipline to both: identify, assess, plan responses, implement, and communicate.

Cause, Event, Effect

PRINCE2 analyses every risk as a three-part chain:

Element Meaning Example

Cause The source or condition that gives rise to the uncertainty 'The supplier is using an unfamiliar technology stack'

Risk event The uncertain occurrence itself — the threat or opportunity 'The team may take longer than estimated to learn the stack' (threat) or 'The team may discover reusable components that accelerate delivery' (opportunity)

Effect The impact on one or more project objectives if the event occurs 'Delivery slips by three weeks and costs rise by 8%' or 'Delivery accelerates by two weeks and costs fall by 5%'

Decomposing a risk this way is not pedantry — it is the foundation for choosing a useful response. You cannot avoid an effect, you can only intervene in the cause or the event. A response that targets the wrong element will fail. Scenario questions frequently describe an effect and ask which cause or event produced it, or describe a cause and ask which risk event flows from it; the cause-event-effect chain is the tool for answering them.

Assessing Risk

Risks are assessed using a combination of factors:

Probability (sometimes called likelihood) — how likely the event is to occur, typically on a scale such as high/medium/low or a percentage.

Impact (sometimes called consequence) — the magnitude of the effect on objectives, often expressed on a monetary, schedule, or qualitative scale.

The combined probability × impact (the expected value) is a common ranking measure, but it is not the whole picture.

Proximity — how soon the risk could materialise. A high-proximity risk demands attention now; a low-proximity risk can be monitored.

Risk tolerance — the threshold of risk the project is willing to bear without a planned response, defined in the Risk Management Approach.

A common exam trap is to assume that the highest probability × impact risk is automatically the top priority. Proximity matters: a moderately scored risk that could occur next week often outranks a slightly higher-scored risk that cannot occur for six months.

Risk Management Approach and Register

The Risk Management Approach is produced by the Project Manager during initiation, included in the PID , and approved by the Project Board . It defines how risk will be managed across the project: the risk categories to be considered (e.g. commercial, technical, operational), the risk tolerance above which a response is mandatory, the roles (Risk Owner, Risk Actionee), the reporting frequency and format, and the techniques to be used for identification and assessment. Producing it is the PM's job; approving it is the board's.

The Risk Register records each identified risk with its cause, event, effect, category, probability, impact, proximity, owner, response, and status. In PRINCE2 v7, the Risk Register is consolidated into the Project Log alongside issues, lessons, and quality checks. The function is unchanged — a single, queryable record of all project risks — but the container has been unified.

Risk Budget vs Contingency

A risk budget is a sum set aside to fund agreed risk responses — it is part of the planned cost of managing risk, not a slush fund. A contingency (sometimes called a contingency reserve) is a buffer held by the Project Board or PM for risks that materialise but were not explicitly planned for. Confusing the two is a frequent exam error. Drawing on the risk budget implies a previously agreed response is being implemented; drawing on contingency implies an unplanned event is being absorbed within tolerance.

Who Owns What

Project Manager produces the Risk Management Approach and is accountable for the day-to-day management of risk on the project.

Project Board approves the Risk Management Approach and owns the project-level risk tolerance; it is also the escalation point for risks beyond PM tolerance.

Risk Owner is the person assigned to manage a specific risk — typically because they have the authority or expertise to influence its causes or responses.

Risk Actionee is the person who carries out the agreed response action on behalf of the Risk Owner. The two roles may be the same person, but they need not be.

Exam Scenario Patterns

Threat vs opportunity. If the scenario describes a possibility of gaining time, cost, or benefit, it is an opportunity; if it describes losing them, it is a threat.

Cause/event/effect. Match each fragment of a scenario to the correct element before reading the question. The cause is the source ; the event is the uncertain occurrence ; the effect is the consequence on objectives .

Risk Management Approach ownership. The PM produces it; the board approves it. This pairing is one of the most heavily tested in the Risk practice.