What Is PRINCE2 Risk Management?
PRINCE2 risk management is the structured approach to identifying, assessing, and controlling uncertainty that could affect a project’s objectives. It involves understanding threats and opportunities, selecting appropriate responses, assigning responsibility, and monitoring whether those responses are working.
In other words, managing risk isn’t simply about writing down everything that could go wrong. It’s about understanding what might happen, deciding what it could mean for the project, and taking appropriate action.
The PRINCE2 Risk Practice helps answer one of Project Management’s most important questions: “What if?”
For example:
- What if a supplier delivers later than expected?
- What if a new technology reduces the work required?
- What if legislation changes during delivery?
- What if an important project assumption turns out to be incorrect?
These uncertainties can affect project decisions long before anything actually happens.
PRINCE2 provides a structured risk-management technique built around five activities: Identify, Assess, Plan, Implement, and Communicate. Communication takes place throughout the other activities, and earlier steps can be revisited as circumstances change.
For an introduction to how this fits into the wider method, explore our guide to the seven PRINCE2 Practices.
What Is a Risk in PRINCE2?
A risk in PRINCE2 is an uncertain event, or combination of events, that would affect project objectives if it occurred. Its significance depends on how likely it is to happen and the extent of its potential impact.
The important word here is uncertain.
A risk hasn’t necessarily happened, and it isn’t always something negative.
Imagine you’re managing a project to introduce a new customer-service platform. Your team identifies two uncertainties:
- An external supplier might not complete an integration on schedule.
- A reusable software component might become available, reducing the amount of development required.
Both are risks because their outcomes are uncertain and could affect the project’s objectives.
However, they wouldn’t be managed in exactly the same way.
What Is the Difference Between a Threat and an Opportunity?
PRINCE2 distinguishes between two types of risk: threats and opportunities.
A threat is an uncertain event that could negatively affect project objectives. An opportunity is an uncertain event that could positively affect them.
| Threat | Opportunity | |
|---|---|---|
| Potential effect | Negative | Positive |
| Example | A supplier may deliver a critical component late | A reusable component may reduce development effort |
| Management aim | Avoid or limit the negative effect | Achieve or increase the positive effect |
| Possible response | Reduce the likelihood of delay | Enhance the chance of achieving the saving |
Consider the supplier example.
If the supplier delivers late, the project may exceed its planned time or cost limits. The Project Manager could investigate alternative suppliers or arrange earlier delivery checks.
On the other hand, suppose the supplier is developing a reusable integration component that could reduce the project’s workload.
The Project Manager might arrange an early technical assessment to increase the likelihood of using that component successfully.
Both situations involve uncertainty, but one requires protection against a negative outcome, while the other creates an opportunity to improve the outcome.
Some circumstances could create either a threat or an opportunity, depending on their effect on objectives. In that situation, it can be useful to describe and assess the different potential effects separately.
What Is the Difference Between a Risk and an Issue in PRINCE2?
A risk concerns uncertainty that could affect objectives. An issue is an event relevant to the project that requires Project Management consideration.
This distinction matters because something that might happen requires a different response from something that has already happened and needs to be addressed.
For example:
Risk: A supplier may miss next month’s integration deadline.
Issue: The supplier has missed the integration deadline, and the team needs to decide how to respond.
The first situation involves uncertainty. The second is a current event requiring attention.
| Consideration | Risk | Issue |
|---|---|---|
| Main characteristic | Uncertain event or events | An event requiring Project Management consideration |
| Example | A supplier may miss a deadline | A supplier has missed a deadline |
| Relevant practice | Risk | Issues |
| Main record | Risk Register | Issue Register where formal management is needed, or another appropriate Project Log record |
| Main activity | Assess uncertainty and plan responses | Assess the current situation and determine appropriate action |
An issue isn’t necessarily a disaster. It might involve a change request, an unexpected development, or an opportunity that now requires a decision.
It’s also important not to assume that every realised risk automatically produces one formal Issue Report. The appropriate treatment depends on the situation and the project’s agreed management procedures.
A useful rule is to ask:
Are we managing something that might affect the project, or responding to an event that now requires consideration?
How Does the PRINCE2 Risk Management Procedure Work?
The current PRINCE2 risk-management technique comprises five steps: Identify, Assess, Plan, Implement, and Communicate.
Although these are often listed in that order, risk management isn’t a process that you complete once and forget.
New risks can emerge, existing assessments may change, and a response that once seemed suitable might no longer be effective.
Communication also takes place continuously rather than being reserved until the end.
Step 1 – Identify
The Identify step establishes the context and objectives that could be affected, then identifies potential threats and opportunities.
It has two parts:
- Define context and objectives.
- Identify threats and opportunities.
Before identifying individual risks, the team needs to understand what the project is trying to achieve.
For instance, a delay only becomes meaningful as a project risk when you understand what it might affect.
Would the delay threaten an agreed delivery date? Increase costs? Prevent a required product from being available?
Once the objectives are understood, the team can identify uncertainties arising from suppliers, assumptions, dependencies, technology, stakeholders, or external circumstances.
Example: A customer-service platform project depends on a specialist supplier completing an integration before the next management stage ends.
The team identifies a risk that limited supplier capacity may delay the integration.
This is recorded in the Risk Register for further assessment.
Step 2 – Assess
The Assess step considers both individual risks and their combined effect on the project.
It also contains two parts:
- Prioritise risks.
- Assess the combined risk profile.
The team evaluates how likely a risk is to occur and how strongly it could affect project objectives.
Other relevant considerations may include how soon the risk might occur and how rapidly its consequences would affect the project.
The Project Manager must also consider the wider picture.
Several individually manageable threats might collectively make the project’s objectives difficult to achieve.
Example: The integration delay is considered reasonably likely and could push completion beyond the agreed stage timetable.
The team also identifies another supplier dependency affecting testing. Together, these threats could create greater overall exposure than either risk considered alone.
Step 3 – Plan
The Plan step determines how the project should respond to the identified risk.
This involves considering response options, deciding who has the authority to manage the risk, and making suitable arrangements for monitoring and action.
The response should be proportionate to the significance of the risk.
For example, it may not make sense to spend thousands of pounds preventing an uncertainty whose potential impact is minor.
However, a risk that could jeopardise a key delivery date may justify more substantial action.
Example: The team decides to reduce the supplier-delay threat by securing earlier confirmation of resource availability and bringing forward a technical review.
The agreed activities are incorporated into the relevant project plans.
Step 4 – Implement
The Implement step puts the chosen responses into action and checks whether they are effective.
Having a response written in the Risk Register isn’t enough.
Someone needs to carry out the agreed work, monitor the result, and identify whether further action is necessary.
Example: The supplier relationship lead obtains a revised resource plan and arranges an early integration demonstration.
The Risk Owner monitors whether those activities reduce the likelihood of delay.
If the response isn’t working, the team considers further corrective action.
Step 5 – Communicate
Communication supports the entire risk-management technique.
The people making decisions need accurate information about emerging threats, opportunities, changes in exposure, agreed actions, and possible effects on project objectives.
Depending on the project’s arrangements, this information may appear in progress reports, project discussions, dashboards, or other agreed communications.
Example: The Project Manager informs relevant stakeholders that the supplier risk has increased and explains what is being done.
If the potential consequences exceed delegated authority or agreed tolerances, the matter may also require escalation.
How Do You Identify and Describe Risks in a PRINCE2 Project?
Effective risk identification begins with understanding project objectives and the uncertainties that could affect them.
A useful starting point is to review assumptions, dependencies, supplier arrangements, estimates, stakeholder expectations, delivery methods, and external conditions.
The team should consider both negative and positive possibilities.
Instead of asking only, “What could go wrong?”, ask, “What could affect our ability to achieve the intended objectives?”
This might uncover opportunities that would otherwise be overlooked.
How Should You Write a PRINCE2 Risk Description?
PRINCE2 uses a cause–event–effect structure to help describe risks clearly.
It separates three things:
- Cause: The circumstances creating the uncertainty.
- Event: What might happen.
- Effect: How the event could affect project objectives.
Compare these two descriptions.
Vague: Supplier delay.
More useful: Because the specialist supplier has limited engineering capacity (cause), the integration work may begin later than planned (event), which could cause the management stage to exceed its agreed time tolerance (effect).
The second description makes it easier to assess the risk and choose a suitable response.
You can see what needs monitoring, why the uncertainty exists, and what consequences the team is trying to prevent.
Build a Better Risk Description
A useful PRINCE2 risk description explains why a risk might arise, what might happen, and how it could affect project objectives.
Let’s see if you can improve a vague risk description using the Cause → Event → Effect structure.
Imagine you’re managing a customer-service platform implementation. A specialist supplier is responsible for integration work that must be completed before the next stage boundary. The supplier currently has limited engineering capacity.
Complete the three parts below. Type your answer into each box, then select Reveal suggested answer to compare your thinking.
The cause explains the circumstances creating the uncertainty.
Reveal suggested answer
Cause: The specialist supplier has limited engineering capacity.
This identifies the circumstances creating the uncertainty rather than simply describing the possible delay.
The risk event describes what might happen. Remember, it must still involve uncertainty.
Reveal suggested answer
Risk event: The integration work may begin later than planned.
Notice the word may. The event hasn’t necessarily happened. We’re describing an uncertainty, not an existing issue.
The effect explains what the risk could mean for the project’s objectives.
Reveal suggested answer
Effect: The management stage could exceed its agreed time tolerance.
This connects the uncertainty to a project objective and explains why the risk matters.
You’ve now considered the cause, event, and effect. Ready to see how they form one useful risk description?
Reveal the Improved Risk Description
Because the specialist supplier has limited engineering capacity, there is a risk that the integration work may begin later than planned, which could result in the management stage exceeding its agreed time tolerance.
This description identifies the circumstances, the uncertain event, and its potential impact on project objectives.
How Are Risks Assessed in PRINCE2?
PRINCE2 risk assessment considers the likelihood of an uncertain event and its potential effect on project objectives.
The current method also recognises proximity and velocity.
These factors help the team understand the urgency, significance, and possible consequences of individual risks.
Risk Probability
Probability describes how likely a risk is to occur.
For example, a supplier with confirmed staffing shortages may present a more likely delivery threat than one with a stable, well-resourced team.
Probability is an estimate, not a guarantee.
The project should use an agreed assessment approach so that the judgements made about different risks are reasonably consistent.
Risk Impact
Impact describes the effect a risk would have on project objectives if it occurred.
A risk might affect:
- Delivery timescales.
- Project costs.
- Scope or product quality.
- Expected benefits.
- Sustainability targets.
- The continued justification for the project.
The same uncertain event can have very different consequences on different projects.
For example, a two-day supplier delay might be relatively minor for one project but critical for another approaching a fixed regulatory deadline.
Risk Proximity
Proximity describes how near in time a risk might occur.
A risk that could happen tomorrow might need immediate attention, while a similar uncertainty expected much later may allow more time to prepare.
However, proximity alone doesn’t determine priority.
A distant risk with severe consequences may still justify early action.
Risk Velocity
Velocity describes how quickly the consequences of a risk would affect project objectives after the risk occurred.
This is different from proximity.
For example, a cyber incident might have an almost immediate operational effect once it occurs.
A supplier capacity issue might develop more gradually before the full effect becomes apparent.
Understanding velocity can help the team judge how much time would be available to respond.
| Factor | Question to ask |
|---|---|
| Probability | How likely is the event? |
| Impact | What effect would it have on objectives? |
| Proximity | How soon might it happen? |
| Velocity | How quickly would the consequences be felt? |
The current guidance includes probability and impact as the minimum basis for qualitative assessment, with proximity and velocity as additional considerations.
How Do You Decide Which PRINCE2 Risks Need the Most Attention?
Risks should be prioritised according to their likely consequences, the project’s context, and the organisation’s willingness and ability to accept uncertainty.
One way to understand individual risks is through a probability-and-impact matrix.
This can help decision-makers see which risks deserve particular attention and whether exposure is changing.
However, a matrix is a decision-support tool, not a substitute for professional judgement.
The Project Manager also needs to consider how risks interact and whether their combined effect makes the project less likely to achieve its objectives.
What Is Risk Appetite in PRINCE2?
Risk appetite is the amount and type of risk the business is willing to accept while pursuing its objectives.
A business may accept considerable uncertainty when exploring an innovative service but have very little appetite for risks that could compromise safety or regulatory compliance.
The project’s approach needs to operate within the appetite established by the business.
What Is Risk Tolerance?
Risk tolerance is a measurable threshold describing the acceptable range of outcomes for an objective exposed to risk.
This helps decision-makers judge whether a particular level of exposure is acceptable and when additional action is needed.
Risk tolerance is related to, but not identical to, performance tolerances used within the wider PRINCE2 governance structure.
The distinction matters because risk-management decisions should consider both the organisation’s tolerance for uncertainty and the authority delegated to manage project performance.
What Is Risk Exposure?
Risk exposure concerns how strongly an objective is affected by uncertainty.
It can be positive or negative.
The combined risk profile matters because several threats or opportunities may alter the overall position of the project.
For example, three moderate supplier dependencies could collectively threaten an important stage objective even if no single dependency initially appears critical.
What Risk Responses Does PRINCE2 Use?
PRINCE2 provides several options for responding to risks.
The appropriate choice depends on the circumstances, the potential consequences, and whether the risk represents a threat or an opportunity.
Responses to Threats
Avoid: Change the circumstances so the threat no longer exists (for example, remove a dependency on an unreliable external interface by selecting a solution that doesn’t require it).
Reduce: Take action to lower the probability or negative impact of the threat (for example, complete an early technical integration test to reduce the likelihood of discovering compatibility problems late in the stage).
Transfer: Arrange for a third party to carry part of the consequences of a risk (for example, use an appropriate insurance or contractual arrangement to address some financial consequences of a potential loss. The project may still retain other effects, such as delays).
Share: Establish an arrangement in which parties share relevant gains or losses (for example, agree a supplier delivery arrangement with shared financial consequences for specific performance outcomes).
Accept: Decide to take the risk without introducing an active response intended to change it (for example, accept a minor potential administrative delay because the likely consequences are within agreed tolerance and further prevention would be disproportionate).
Prepare contingent plans: Decide in advance what to do if circumstances change or an initial response is unsuccessful (for example, prepare an alternative testing sequence that can be activated if the integration isn’t available by an agreed date).
These options aren’t necessarily mutually exclusive. A project may reduce a threat while also preparing a contingent plan.
Responses to Opportunities
Exploit: Act to make the beneficial outcome happen (for example, secure access to an available reusable software component so the team can incorporate it into the delivery approach).
Enhance: Increase the likelihood or positive effect of an opportunity (for example, arrange an early technical demonstration to improve the chances of adopting a component that could reduce development work).
PRINCE2 also recognises that transferring, sharing, accepting, or preparing contingent plans may be relevant to opportunities, depending on the situation.
This means the response options shouldn’t be treated as two completely separate lists.
How Do You Choose the Best Risk Response?
A suitable response should be appropriate to the possible impact and worth the effort or resources required.
Consider three questions:
- What change in risk exposure would the response achieve?
- What would implementing it cost or require?
- Would the remaining risk be acceptable?
A response can also create new risks.
For instance, switching suppliers to avoid a possible delay might introduce compatibility or procurement risks.
These secondary risks need consideration, too.
What Is a Risk Owner in PRINCE2?
A Risk Owner is the person assigned responsibility for managing and responding to a particular risk.
The Risk Owner is concerned with the overall risk, rather than simply completing one task.
Their responsibilities include monitoring the risk, overseeing its treatment, and checking whether agreed responses remain effective.
What Is a Risk Action Owner?
A Risk Action Owner is the person nominated to carry out an agreed action in response to a risk.
They may be different from the Risk Owner, particularly when a response requires specialist expertise or authority.
For example, the Project Manager might own a supplier-delivery risk, while a technical lead is responsible for completing the integration test intended to reduce that risk.
The Risk Action Owner should keep the Risk Owner informed about progress and results.
| Role | Main responsibility | Example |
|---|---|---|
| Risk Owner | Manages and monitors the overall assigned risk | Project Manager oversees the supplier-delay threat |
| Risk Action Owner | Carries out a specific agreed response action | Technical lead completes an early integration test |
The same person can perform both roles where appropriate.
The important requirement is that responsibilities are clear and agreed.
For a wider explanation of accountability across the method, see our PRINCE2 roles and responsibilities guide.
What Is the PRINCE2 Risk Register?
The PRINCE2 Risk Register is a record of identified project risks, including their current status and history.
It helps the project team capture and maintain information about threats and opportunities so they can be assessed, assigned, monitored, and managed.
However, maintaining the Risk Register is not the same as managing risk.
A register can show what has been identified, but it doesn’t carry out actions or make decisions.
What Information Goes Into a PRINCE2 Risk Register?
The current manual identifies the following high-level information:
- A unique risk identifier.
- A description covering cause, event, and effect.
- Probability and impact assessments.
- Proximity and velocity.
- Chosen risk responses.
- Planned residual probability and impact.
- Risk Owner and Risk Action Owner details.
- Relevant dates, including reviews and action deadlines.
- References to associated records.
The exact structure and level of detail should follow the project’s tailored risk management approach.
Example Risk Register Entry
| Field | Illustrative entry |
|---|---|
| Risk identifier | R-014 |
| Description | Limited supplier capacity could delay integration and threaten stage time tolerance |
| Probability | Medium |
| Impact | High |
| Proximity | Within the next four weeks |
| Velocity | Consequences may affect the stage schedule quickly |
| Response | Reduce: confirm resources and conduct early integration testing |
| Planned residual probability | Low |
| Planned residual impact | Medium |
| Risk Owner | Project Manager |
| Risk Action Owner | Technical Integration Lead |
| Next review | Next scheduled project risk review |
| Related records | Supplier resource plan and integration test schedule |
Illustrative educational entry. Actual recording should follow the project’s agreed scales and risk management approach.
Where Does the Risk Register Sit in the Project Log?
In current PRINCE2, the Risk Register forms part of the Project Log.
The Project Log brings together records that support day-to-day project management, including risks, issues, lessons, and other relevant information.
The records can be maintained separately or through a shared system, depending on the project’s arrangements.
Our PRINCE2 Management Products guide explains the wider structure.
What Is the Risk Management Approach in PRINCE2?
The risk management approach explains how risk will be managed on a particular project.
It forms part of the Project Initiation Documentation (PID) and establishes how the project will apply risk-management activities.
This can include the agreed procedure, responsibilities, assessment standards, tolerances, techniques, recording arrangements, and reporting requirements.
The distinction is straightforward:
- Risk Practice: The ongoing management of uncertainty within PRINCE2.
- Risk management approach: How the project has agreed to carry out that management.
- Risk Register: Where information about identified risks is recorded.
For example, the risk management approach may define how probability and impact are assessed and how frequently significant risks are reviewed.
The Risk Register then contains information about the actual risks.
When Should a PRINCE2 Risk Be Escalated?
A PRINCE2 risk should be escalated when its management or consequences require a decision beyond the authority delegated to the current management level.
This may happen when the proposed response would exceed agreed tolerances, when the team lacks authority to manage the risk, or when the consequences could materially affect the project’s justification.
Not every identified risk needs to go directly to the Project Board.
Where the risk falls within the relevant tolerances and the Project Manager has authority to choose a response, it can normally be managed at that level.
When it falls outside that authority, the decision needs to move to the appropriate higher level.
For example, a supplier delay can be accommodated within the current stage timetable. The Project Manager decides on a suitable response.
Later, revised information suggests the delay will exceed agreed stage time tolerance.
The Project Manager can no longer treat the matter as simply a routine risk-management decision within delegated authority. Appropriate escalation is required.
The aim is to enable timely decisions, not to wait until the adverse outcome becomes unavoidable.
How Does Risk Management Connect to Management by Exception?
PRINCE2 Management by Exception allows decisions to be delegated within defined limits.
Different management levels are given authority to manage their work within agreed tolerances.
Risk management supports this principle by identifying uncertainties that could affect performance or require higher-level decisions.
For example, if a risk threatens an agreed stage time tolerance, the Project Manager needs to consider the forecast consequences and the relevant escalation arrangements.
This helps the Project Board focus on decisions that require its authority rather than reviewing every minor uncertainty.
It’s also important to distinguish a risk requiring higher-level attention from an actual or forecast breach of performance tolerance. The relevant response must follow the project’s current governance and exception-management procedures.
Explore our guide to Management by Exception for more detail.
How Does Risk Affect the PRINCE2 Business Case?
Risk can influence whether a project remains justified.
A project may have a strong Business Case when authorised, but changing circumstances can affect the expected costs, benefits, feasibility, or likelihood of achieving the intended outcomes.
For example, an increased probability of supplier failure could raise expected costs or delay benefits.
Alternatively, an emerging opportunity might improve the expected return on the investment.
Risk management therefore helps decision-makers consider whether continuing with the project remains appropriate.
This connects directly with the PRINCE2 principle of ensuring continued business justification.
When Should Risks Be Reviewed?
Risks should be reviewed throughout the project, particularly when new information could change their probability, impact, urgency, or appropriate response.
PRINCE2 doesn’t require every project to use one universal review frequency.
The timing and method should be established through the tailored risk management approach.
Relevant occasions include regular project management activity, planning and reporting, changes to assumptions or dependencies, and management stage boundaries.
Why Do Risks Change Throughout a Project?
A threat can become more likely as a deadline approaches.
An opportunity can disappear because the circumstances that made it possible have changed.
A successful response might reduce a risk to an acceptable level.
New risks can also appear when delivery methods, suppliers, stakeholders, or objectives change.
For that reason, a Risk Register should reflect the project’s current position, not simply provide a history of risks identified at initiation.
At stage boundaries, decision-makers should be able to consider the risk profile when deciding whether the next management stage should proceed.
Who Is Responsible for Risk Management in PRINCE2?
Risk management involves several roles, with responsibilities distributed across the project’s governance structure.
Risk Management Responsibilities in PRINCE2
| Role | Main risk-management focus |
|---|---|
| Business layer | Provides organisational risk requirements and sets project-level appetite, tolerance, and risk budget |
| Project Executive | Oversees the suitability of the approach, risks to the Business Case, and decisions on escalated risks |
| Senior User | Focuses on risks affecting users, benefits, and operational outcomes |
| Senior Supplier | Focuses on supplier and solution-delivery risks |
| Project Manager | Maintains the approach and register and ensures risks are identified, assessed, and controlled |
| Team Manager | Applies agreed risk procedures to assigned work and participates in risk activities |
| Project Assurance | Reviews whether risk management follows the agreed approach and provides assurance |
| Project Support | Supports risk administration and maintenance of the register |
Individual Risk Owners and Risk Action Owners perform their specific assigned responsibilities within these arrangements.
Effective risk management also depends on the wider project ecosystem. Team members, suppliers, business representatives, and stakeholders may identify useful information about emerging risks.
How Should PRINCE2 Risk Management Be Tailored?
PRINCE2 risk management should be tailored to the size, complexity, delivery method, organisational requirements, and potential impact of the project.
This doesn’t mean that smaller projects can ignore uncertainty.
It means the way risks are documented, assessed, monitored, and communicated should support decisions without creating unnecessary administration.
For example, a straightforward internal improvement project might maintain its risks in a simple spreadsheet and review them during regular project meetings.
A complex programme involving multiple suppliers, sensitive systems, and significant regulatory obligations may need specialist analysis, more structured reporting, and extensive coordination.
The risk-management arrangements should also reflect how serious the potential consequences could be.
A small project affecting critical business infrastructure may require stronger controls than its budget or team size would initially suggest.
See our guide to tailoring PRINCE2 for the wider principles.
Does PRINCE2 Risk Management Work With Agile and Hybrid Delivery?
Yes. PRINCE2 risk management can be tailored to different delivery approaches, including iterative, incremental, and hybrid projects.
The need to identify, assess, and manage uncertainty remains, even when work is delivered in shorter cycles.
In an iterative environment, new information may emerge frequently through demonstrations, testing, reviews, and stakeholder feedback.
That information can help project teams reassess risks and adjust responses.
For example, an early product increment might reveal an integration problem sooner than originally expected.
The Risk Register and relevant plans can then be updated, with communication and escalation following the agreed project arrangements.
PRINCE2 doesn’t require every Agile team to operate a separate, invented risk procedure.
Instead, the risk management approach should fit the delivery context while continuing to meet the project’s governance needs.
PRINCE2 Risk Management Example: A Supplier Delay
Imagine a fictional project implementing a new customer-service platform.
The project includes a specialist integration that must be completed before a critical stage-end demonstration.
The supplier has recently experienced staffing difficulties, but the project hasn’t yet confirmed whether those difficulties will affect delivery.
Here’s how the team could manage the uncertainty using PRINCE2.
1. Identify the Risk
The team reviews its delivery objectives and identifies the integration deadline as a potential area of uncertainty.
It records the risk using a cause–event–effect description:
Cause: The supplier has limited access to specialist integration engineers.
Event: The integration may be delivered later than planned.
Effect: Testing and the stage-end demonstration may be delayed, potentially exceeding time tolerance.
The risk is entered into the Risk Register.
2. Assess the Risk
The Project Manager works with the relevant team members to consider:
- How likely the delay is.
- What effect it would have on the schedule and other objectives.
- How soon the delay might become apparent.
- How rapidly it would affect the stage once it occurred.
The team also examines whether this threat, together with other supplier risks, could affect the project’s overall exposure.
3. Plan the Response
The team chooses to reduce the threat.
The proposed response includes obtaining a confirmed supplier resource plan, arranging an early technical demonstration, and reviewing the integration schedule.
It also prepares an alternative testing sequence that could be activated if the original delivery plan becomes unworkable.
The agreed actions are incorporated into the relevant plans.
4. Implement the Response
The Project Manager is assigned as the Risk Owner.
The Technical Integration Lead is assigned as a Risk Action Owner for the early technical assessment.
The lead arranges the assessment, reports the results, and identifies any remaining problems.
The Risk Owner reviews whether the probability and impact have changed.
5. Communicate and Review
Risk information is shared as appropriate throughout the project.
The Project Manager updates the Risk Register and reports any significant changes.
If the latest information indicates that the risk or its proposed response exceeds delegated tolerance or authority, the decision is escalated appropriately.
Otherwise, the team continues managing it within the agreed arrangements.
If the supplier actually misses the deadline, the resulting event may also need to be addressed through the Issues Practice.
This example demonstrates why risk management is much more than recording a possible delay. The value comes from making decisions and taking action while there is still an opportunity to influence the outcome.
PRINCE2 Opportunity Example
Now imagine the supplier develops a reusable integration component that could substantially reduce the work needed.
This creates a potential opportunity.
The team identifies and assesses the uncertainty, including the likelihood that the component will become available and the benefits it could deliver.
A suitable response would depend on how much control the team has over the opportunity.
For example, the team might choose to enhance the opportunity by arranging an early technical evaluation, increasing the likelihood that the component can be used successfully or improving the potential benefits.
Alternatively, if the project can secure access to the component and take the necessary steps to achieve the beneficial outcome, the team could choose to exploit the opportunity.
The distinction is important: enhancing an opportunity increases its probability or positive impact, whereas exploiting an opportunity aims to make the beneficial outcome certain.
In either case, the Risk Owner would monitor whether the expected benefit is achievable, ensure agreed actions are carried out, and consider whether pursuing the opportunity introduces any additional risks.
This demonstrates that PRINCE2 risk management isn’t only about preventing problems. It’s also about identifying and actively pursuing opportunities that could improve project outcomes.
Common PRINCE2 Risk Management Mistakes
Even a well-maintained Risk Register is of limited value if risks aren’t actively managed.
Common mistakes include:
- Treating all risks as threats. This overlooks opportunities that could improve outcomes.
- Confusing risks with issues. Uncertain events and current events require different consideration.
- Writing vague descriptions. A phrase such as “supplier problem” doesn’t explain the uncertainty or its effect.
- Assigning actions without clear responsibility. Someone must manage the overall risk and someone must carry out each agreed action.
- Assessing risks individually without reviewing combined exposure. Several manageable threats can collectively create a serious problem.
- Assuming a numerical rating tells the whole story. Probability, impact, timing, context, and tolerances all matter.
- Recording responses but never implementing them. A planned action isn’t an accomplished action.
- Failing to review risks as circumstances change. Old assessments can become unreliable.
- Escalating every minor risk. Risk decisions should be managed at the appropriate authorised level.
- Using unnecessarily complicated arrangements. The management effort should be proportionate to the project’s circumstances.
The common theme is that good risk management depends on judgement, responsibility, and action.
A Practical PRINCE2 Risk Checklist
Before deciding that a project risk is being managed effectively, ask:
- Have we identified the relevant objective?
- Is the situation uncertain, or is there already an issue?
- Is the potential effect a threat, an opportunity, or both?
- Have we described the cause, event, and effect?
- Have we assessed probability and impact?
- Do proximity and velocity affect the urgency of our response?
- Have we considered the combined risk exposure?
- Is there an agreed response that is proportionate to the risk?
- Is there a Risk Owner?
- Does every agreed response action have an appropriate owner?
- Are actions being implemented and reviewed?
- Have we recorded the relevant details in the Risk Register?
- Could the risk or response require escalation?
- Are the right people receiving updated information?
These questions can help turn risk management from a documentation exercise into a practical part of project delivery.
Frequently Asked Questions About PRINCE2 Risk Management
What is PRINCE2 risk management?
PRINCE2 risk management is the structured identification, assessment, and control of uncertainty affecting project objectives. It includes threats and opportunities, risk responses, ownership, monitoring, communication, and escalation where required.
What is the PRINCE2 Risk Practice?
The Risk Practice is one of the seven PRINCE2 Practices. It addresses uncertainty that could affect project objectives and supports informed decisions about how the project should respond.
What is the PRINCE2 risk management procedure?
The current PRINCE2 technique comprises Identify, Assess, Plan, Implement, and Communicate. Communication occurs throughout, and earlier activities can be repeated as information changes. Projects may tailor the technique or adopt an appropriate alternative where the tailoring is documented.
Does PRINCE2 manage opportunities as risks?
Yes. PRINCE2 recognises both threats and opportunities as risks. Threats have potentially negative effects, while opportunities have potentially positive effects on project objectives.
What is the difference between a risk and an issue?
A risk is an uncertain event or set of events that could affect objectives. An issue is an event relevant to the project that requires Project Management consideration. A possible supplier delay is a risk; an actual missed delivery deadline may create an issue.
What is a PRINCE2 Risk Register?
The Risk Register is a record of identified threats and opportunities, including their assessments, responses, owners, status, and history. It forms part of the Project Log and supports ongoing risk management.
Who owns a risk in PRINCE2?
A designated Risk Owner is responsible for managing and monitoring an assigned risk. The person should have suitable capability and responsibility for ensuring that the risk is treated appropriately.
What is a Risk Action Owner?
A Risk Action Owner is the person assigned to carry out a particular response action. They may be different from the Risk Owner, who remains responsible for the overall assigned risk.
What risk responses does PRINCE2 use?
PRINCE2 includes avoiding threats, exploiting opportunities, reducing threats, enhancing opportunities, transferring risks, sharing risks, accepting risks, and preparing contingent plans. The right response depends on the risk, its potential consequences, and the project’s circumstances.
When should a PRINCE2 risk be escalated?
Escalation is appropriate when managing the risk or making the required decision exceeds the relevant delegated authority or tolerances. Depending on the circumstances, the matter may need consideration by the Project Board or another appropriate governance level.
How often should the Risk Register be reviewed?
The review frequency should follow the project’s risk management approach. Risks also need reassessment when new information emerges, responses change, or significant events affect the project’s objectives.
Can PRINCE2 risk management be tailored for Agile projects?
Yes. PRINCE2 risk management can operate alongside iterative and hybrid delivery methods. Assessment, monitoring, communication, and recording can be adapted to the way the project delivers work, while maintaining appropriate governance.
What Should You Explore Next?
PRINCE2 risk management is about making better decisions in the face of uncertainty.
The Risk Register provides a useful record, but successful risk management requires much more: clear descriptions, informed assessments, appropriate responses, accountability, regular reviews, and timely communication.
If you’re studying PRINCE2, understanding how these activities connect will help you move beyond memorising terminology.
If you’re already working on projects, the same principles can help you respond to uncertainty before it affects delivery.
You can explore the wider method through our introduction to PRINCE2 Project Management.
Not sure which PRINCE2 qualification fits your Project Management goals?
