Risk vs Issue in PRINCE2®
The main difference between a risk and an issue in PRINCE2 is uncertainty. A risk is an uncertain event that could affect project objectives if it occurs. An issue is an event relevant to the project that requires management consideration now. When a risk materialises, the resulting situation may need to be managed as an issue.
| Comparison | Risk | Issue |
|---|---|---|
| Main distinction | Uncertain | A current event or matter requiring consideration |
| Key question | What if? | What now? |
| Potential outcome | Negative or positive | Negative or positive |
| PRINCE2 Practice | Risk | Issues |
| Main formal record | Risk Register | Issue Register |
| Responsibility | Risk Owner and Risk Action Owner | Issue Owner and relevant decision-making authorities |
| Main approach | Identify, assess, plan responses, and control uncertainty | Capture, assess, recommend, decide, and implement appropriate action |
| Example | A supplier may miss a delivery date | The supplier has confirmed a delivery delay |
Risk vs Issue in PRINCE2: What’s the Main Difference?
A risk concerns something that might happen. An issue concerns an event or situation relevant to the project that needs consideration.
For example, imagine you’re managing a project that depends on an external supplier.
Risk: “The supplier may deliver the integration component two weeks late.”
The delivery delay is uncertain. It might happen, but it has not been confirmed.
Issue: “The supplier has confirmed that the integration component will arrive two weeks late.”
The delay is now known. The Project Manager needs to assess its impact and determine what action is required.
This difference matters because PRINCE2 provides separate practices for managing uncertainty and handling issues.
However, the distinction is not simply that risks are future problems and issues are past problems. Risks can be opportunities, while issues can include current opportunities, concerns, and proposals for change.
What Is a Risk in PRINCE2?
A risk in PRINCE2 is an uncertain event, or combination of events, that would affect the achievement of objectives if it occurred.
The important elements are:
- Uncertainty: The event is not certain to occur.
- Probability: There is an estimated chance of the event happening.
- Impact: The event could affect the project’s objectives.
PRINCE2 uses its Risk Practice to identify, assess, and control these uncertainties.
For example, a project introducing a new customer service platform might identify a risk that an external software integration could fail under heavy demand.
The integration has not necessarily failed. However, the potential failure could affect delivery timescales, costs, or product quality.
The Project Manager can assess the risk, determine an appropriate response, and monitor it throughout the project.
For a deeper explanation, see our PRINCE2 Risk Management guide.
Threats and Opportunities
Not every risk is negative.
PRINCE2 distinguishes between two possible outcomes:
- Threat: An uncertain event that could negatively affect project objectives.
- Opportunity: An uncertain event that could positively affect project objectives.
For example, a potential shortage of specialist developers is a threat because it could delay delivery.
However, the possibility that a supplier will release a reusable software component is an opportunity because it could reduce the amount of development work required.
Both are risks while their occurrence remains uncertain.
What Is an Issue in PRINCE2?
An issue in PRINCE2 is an event relevant to the project that requires project management consideration.
Issues may arise from unexpected problems, concerns raised by stakeholders, external developments, requests for change, or opportunities that become available.
For example, a stakeholder might request an additional feature for a software product.
Nothing has necessarily gone wrong. However, the proposal requires consideration because it could affect the agreed scope, cost, or delivery schedule.
Similarly, a supplier might confirm that a component will arrive late. The Project Manager must assess the effect on the project and determine whether corrective action or escalation is necessary.
The purpose of the Issues Practice is to collect and assess such matters and control any resulting changes to the project baseline.
What Types of Issues Does PRINCE2 Recognise?
PRINCE2 Version 7 recommends classifying issues into five categories.
Problem or Concern
A problem is an issue with an immediate negative impact. A concern is an issue whose timing and impact need assessment.
For example, a project system that has stopped working is a problem.
A stakeholder expressing concern about the accessibility of a planned service may also be raising an issue that requires investigation.
Not every concern will lead to a change, but it should be considered appropriately.
Event External to the Project
An external event is a development outside the project’s control that may affect its objectives or delivery.
For example, an external supplier going out of business could force the project to reconsider its procurement arrangements.
Although the project did not cause the situation, the Project Manager may still need to assess and respond to its consequences.
Business Opportunity
A business opportunity is an issue involving unexpected positive consequences for the project or user organisation.
For example, a new piece of equipment with improved capabilities becomes available at a lower price than the originally selected equipment.
The team may need to decide whether taking advantage of the opportunity is worthwhile.
This is an important distinction: an issue does not have to be negative.
An uncertain positive event is a risk opportunity. Once a relevant opportunity arises and requires consideration, it may be handled as a business opportunity issue.
Request for Change
A request for change is a proposal to modify an approved baseline.
For example, a stakeholder might ask for a new reporting feature to be added to an agreed software product.
Because the product requirements have already been approved, the proposal needs to be assessed through the project’s change control arrangements.
A request does not automatically mean the change will be approved.
Off-Specification
An off-specification occurs when a product will not meet its agreed quality specifications.
For example, a system may have been specified to support 2,000 simultaneous users, but testing reveals that it can only support 1,200.
The Project Manager must consider how this discrepancy should be resolved.
Depending on the circumstances, the project may undertake corrective work or escalate the off-specification for a decision. In PRINCE2, a concession is an off-specification accepted by the Project Board without corrective action.
What Happens When a Risk Actually Happens?
When a risk event occurs, the uncertainty surrounding that particular event has been resolved.
If the event creates a situation that requires project management consideration, it may need to be handled through the Issues Practice.
Consider a supplier delay.
Initially, the project team identifies the possibility that an essential component will not arrive on time. This is a risk because the delay is uncertain.
The team assesses the probability and impact, assigns responsibility, and plans appropriate responses.
Later, the supplier confirms that the component will arrive two weeks late.
The Project Manager now needs to assess the confirmed delay, consider its impact on the relevant plans, and determine what action is necessary.
Does a risk automatically become an issue?
No. PRINCE2 does not require an automatic conversion of every materialised risk into an issue.
The project team should review the risk’s status, consider whether the resulting situation requires issue management, and update the appropriate records.
For example, an existing contingency arrangement might be sufficient to address the consequences of a materialised risk. The Project Manager should still review the risk’s status and determine whether the resulting situation needs to be captured and managed as an issue under the project’s agreed procedures. A materialised risk may also introduce new uncertainties requiring separate risk management.
Risk Register vs Issue Register: What’s the Difference?
The Risk Register records identified threats and opportunities affecting the project, while the Issue Register records issues requiring formal management.
Both provide information needed to make and monitor project management decisions.
| Record | What it captures | Typical information |
|---|---|---|
| Risk Register | Identified uncertainties | Risk description, probability, impact, responses, ownership, status, and relevant dates |
| Issue Register | Formally managed issues | Issue description, type, priority, severity, ownership, decisions, status, and dates |
Where Do These Registers Sit?
In PRINCE2, both the Risk Register and Issue Register form part of the Project Log.
The Project Log brings together continually changing project information, including records of risks, issues, lessons, quality activities, products, and informal actions.
These records do not necessarily need to exist as separate spreadsheets or documents. PRINCE2 allows management information to be maintained in a variety of formats, including integrated systems.
Read our PRINCE2 Management Products guide for more information.
When Is the Daily Log Used?
The Daily Log records informal issues, actions, or significant events that are not captured through other PRINCE2 management products.
For example, if a project office printer stops working and a team member can arrange a straightforward repair, the matter may be recorded informally in the Daily Log.
In contrast, a supplier delivering a product that will not meet its agreed specifications could require formal management through the Issue Register.
The Daily Log may also temporarily capture issues and risks during Starting Up a Project, before the relevant registers have been established.
The distinction is based on the project’s agreed management arrangements and the need for formal consideration, rather than an arbitrary monetary threshold.
What Is an Issue Report?
An Issue Report provides a more detailed assessment of an issue, including its impact on the project baseline, possible responses, and a recommended decision.
Not every issue needs a separate, detailed Issue Report.
For some issues, the information in the Issue Register is sufficient to assess the situation and agree an action.
More significant issues may require a formal report to support the decision-making process.
Risk Practice vs Issues Practice: How Are They Different?
The Risk Practice and Issues Practice are two of the seven PRINCE2 Practices.
They address different management needs.
Risk Practice — “What if?”
The Risk Practice helps the team identify, assess, and control uncertainties that could affect project objectives.
Its focus is on understanding potential events and deciding how to respond to them.
Issues Practice — “What now?”
The Issues Practice collects and assesses issues and controls changes to the project’s baseline.
Its focus is on considering events, concerns, proposals, and developments that require attention.
Both practices are applied throughout the project lifecycle. They also interact with planning, progress monitoring, quality management, and the Business Case.
Explore the wider framework in our guide to the seven PRINCE2 Practices.
Who Is Responsible for Risks and Issues?
PRINCE2 distinguishes between responsibility for a risk, responsibility for its response actions, and the management of issues.
| Responsibility | What it means |
|---|---|
| Risk Owner | Takes responsibility for responding to an identified risk |
| Risk Action Owner | Carries out an agreed action intended to respond to a risk |
| Issue Owner | The person identified as responsible for an issue in the Issue Register |
| Project Manager | Manages the relevant risk and issue procedures within delegated authority |
| Project Board or delegated authority | Makes decisions where the matter requires higher-level authorisation |
An Issue Owner identifies who is responsible for an issue within the Issue Register, but this should not be confused with having the authority to approve every proposed resolution. Decisions must still be made by the appropriate person or management level, according to the project’s agreed responsibilities and delegated authority.
For example, the Project Manager might assign a Risk Owner to oversee the possibility of a supplier delay.
A Risk Action Owner could then be responsible for contacting an alternative supplier or arranging an agreed contingency.
If the delay becomes a current issue, its management follows the project’s issue arrangements, with an Issue Owner recorded where the Issue Register is used.
The appropriate decision-maker depends on the nature of the issue, its impact, and the authority delegated within the project.
How Are Risks and Issues Assessed and Managed Differently?
Risks and issues both require assessment, but the questions differ.
Risk assessment focuses on uncertainty. PRINCE2 considers factors including probability, impact, proximity, and velocity.
The team considers how likely a threat or opportunity is to occur, how it might affect objectives, when it could happen, and how quickly its impact might be felt.
Responses can then be chosen and implemented to manage the uncertainty.
Issue assessment focuses on the event or matter requiring consideration.
The team determines the issue type, assesses its relevance and potential impact, considers resolution options, and recommends an appropriate decision.
For significant issues, the assessment may need to consider the implications for the project’s plans, objectives, Business Case, and baseline.
An important principle is that not every issue requires a change.
Sometimes the right response is to reject a proposal, take no further action, or resolve the matter within existing arrangements.
Are All Issues Changes?
No. All issues do not automatically result in changes to the project baseline.
PRINCE2 distinguishes between identifying an issue and deciding whether an approved baseline needs to change.
For example, a stakeholder asking for an additional feature raises a request for change.
The Project Manager assesses the proposal, including the implications for cost, time, scope, and expected benefits.
The appropriate decision-maker may approve, reject, or defer the proposal.
If the request is rejected, no change to the approved baseline is required.
Similarly, a problem might be corrected without changing the agreed scope or quality requirements.
A confirmed off-specification, however, must be addressed through the relevant change control procedure. If it is accepted as a concession, the project baseline must be updated accordingly.
How Do Risks and Issues Affect Tolerances and Escalation?
Risks and issues can both affect the project’s agreed performance targets.
PRINCE2 uses tolerances to establish how far performance may deviate from approved plans without requiring escalation.
These apply to seven aspects of performance:
- Benefits
- Cost
- Time
- Quality
- Scope
- Sustainability
- Risk
Under the Manage by Exception principle, decisions should be made within delegated authority wherever possible.
A Project Manager does not need to escalate every risk or issue simply because it is important.
However, if a relevant plan’s tolerances are forecast to be exceeded, the matter must be escalated to the next management level for a decision.
For example, imagine a delivery delay that can be absorbed within the current Stage Plan’s time tolerance.
The Project Manager may be able to manage the situation using existing authority.
If the delay means the stage is forecast to exceed its permitted time tolerance, escalation is required.
Risks and issues can also affect the project’s continued business justification. Significant changes to expected benefits, costs, or delivery viability may require the Business Case to be reviewed.
Read our PRINCE2 Manage by Exception guide for further guidance.
Risk vs Issue Examples in PRINCE2
The following original examples show how the same project situation can move from uncertainty to an event requiring management consideration.
| Scenario | Risk | Issue |
|---|---|---|
| Supplier | The supplier may deliver late | The supplier confirms a delay |
| Technology | The integration may fail under peak demand | Testing confirms the integration cannot support the required demand |
| Resources | A key specialist may leave | The specialist has resigned |
| Regulation | Proposed legislation may introduce additional requirements | New legislation is enacted and requires the project to reconsider compliance |
| Quality | A product may fail acceptance testing | Testing identifies a failure against agreed criteria |
| Costs | Material prices may increase | The supplier confirms an increased price |
| External event | Severe weather may interrupt delivery | Flooding has closed a delivery route |
| Opportunity | An improved component may become available | An improved component is available, and the team must decide whether to adopt it |
The issue classifications in these examples assume that the events are relevant to the project and require consideration. A newly enacted law, for example, would only be a project issue where it has implications for that project.
Worked Example: From Supplier Risk to Current Issue
Imagine a fictional project introducing a new digital customer-service platform.
The team depends on an external supplier to provide an integration component before system testing begins.
Step 1 – Identify the Risk
The project identifies the possibility that the supplier will miss the agreed delivery milestone.
The potential consequence is a delay to system testing and the subsequent launch.
The risk is recorded in the Risk Register, assessed, and assigned to a Risk Owner.
Step 2 – Prepare a Risk Response
The project team agrees a response intended to reduce the consequences of a potential delay.
For example, an alternative testing sequence could be prepared, allowing some work to continue while the integration component is outstanding.
A Risk Action Owner is nominated to carry out the agreed response actions.
Step 3 – The Supplier Confirms the Delay
The supplier confirms that delivery will be two weeks late.
The original uncertainty has now become a known situation.
The Project Manager reviews the relevant risk and assesses whether a formal issue should be raised under the agreed issue management approach.
Step 4 – Assess the Current Impact
The Project Manager considers:
- Which planned activities will be affected?
- Can the agreed contingency reduce the delay?
- Will additional costs be incurred?
- Is the stage still forecast to remain within tolerance?
- Are there implications for quality, benefits, or continued justification?
The relevant issue information is recorded, and an Issue Report is prepared if more detailed analysis is required.
Step 5 – Decide, Act, and Update
If the delay can be managed within delegated authority, the Project Manager arranges the appropriate corrective action.
If a relevant tolerance is forecast to be exceeded, the matter must be escalated.
The team also reviews the original Risk Register entry and updates the relevant issue information, plans, and other records as necessary.
This example illustrates why risk management and issue management need to work together, rather than operate as isolated administrative processes.
Common Mistakes When Managing Risks and Issues
1. Calling every problem a risk
A known problem requiring attention is not the same as an uncertain event.
2. Assuming risks are always negative
PRINCE2 includes both threats and opportunities.
3. Treating every issue as a problem
Issues also include concerns, business opportunities, external events, change requests, and off-specifications.
4. Assuming a materialised risk automatically becomes an issue
The resulting situation should be assessed according to the project’s management arrangements.
5. Confusing the Risk Register and Issue Register
One records identified uncertainties, while the other records formally managed issues.
6. Escalating every issue to the Project Board
Delegated authority and agreed tolerances determine when escalation is required.
7. Forgetting to update the relevant records
Risk status, issue decisions, responsibilities, and affected plans need to reflect the current situation.
Is It a Risk or an Issue? A Quick PRINCE2 Test
When you encounter something that could affect a project, ask two questions:
Question 1: Is it uncertain whether the event will occur?
If yes, it is likely to be a risk. Identify and assess it using the project’s risk management approach.
Question 2: Is there an event, proposal, or situation relevant to the project that requires consideration now?
If yes, it is likely to be an issue. Capture and assess it using the project’s issue management approach.
Some situations can create both current issues and further uncertainties, so the two practices may need to be applied together.
Frequently Asked Questions
What Is the Difference Between a Risk and an Issue in PRINCE2?
A risk is an uncertain event that could affect project objectives. An issue is an event relevant to the project that requires management consideration. Risks are managed through the Risk Practice, while issues are handled through the Issues Practice.
Is a Risk Something That Hasn’t Happened Yet?
A risk involves uncertainty about whether an event or set of events will occur. If the event materialises, the risk should be reviewed, and any resulting situation requiring consideration may need issue management.
Does a Risk Automatically Become an Issue?
No. A materialised risk may produce an issue, but PRINCE2 does not prescribe a universal automatic conversion. The project team should assess what has occurred and update the relevant records.
Where Are Risks Recorded in PRINCE2?
Identified risks are recorded in the Risk Register, which forms part of the Project Log. During project start-up, the Daily Log can temporarily capture risk information before the register has been established.
Where Are Issues Recorded in PRINCE2?
Formally managed issues are recorded in the Issue Register. Informal issues may be recorded in the Daily Log, depending on the nature of the matter and the project’s agreed management arrangements.
What Are the Five Types of Issues in PRINCE2?
PRINCE2 Version 7 identifies a problem or concern, an event external to the project, a business opportunity, a request for change, and an off-specification.
What Is an Off-Specification?
An off-specification is a product that will not meet its agreed quality specifications. It must be considered through the relevant change control arrangements.
Is a Request for Change an Issue?
Yes. A request for change is one category of issue. It is a proposal to change an approved baseline, but it does not mean the proposed change will necessarily be authorised.
Can an Opportunity Become an Issue?
Yes. An uncertain positive event is a risk opportunity. If a positive development arises and requires current project management consideration, it may be handled as a business opportunity issue.
When Should a Risk or Issue Be Escalated?
A risk or issue must be escalated when its consequences mean that an agreed tolerance is forecast to be exceeded. Other matters may also require higher-level decisions where the relevant authority has not been delegated.
What Should You Explore Next?
Understanding the difference between risks and issues is an important part of applying PRINCE2 effectively.
The key is to recognise whether you are dealing with uncertainty or a current situation that requires consideration, then use the appropriate practice, records, and decision-making arrangements.
To explore the wider method, start with our guides to PRINCE2 Risk Management, PRINCE2 Practices, and PRINCE2 Management Products.
Want to develop the knowledge needed to understand and apply PRINCE2 in practice?
Want to build stronger practical PRINCE2 Project Management skills?
