PRINCE2 2017 Risk Theme and Risk Management Procedure
Manage uncertainty as a continuous decision process: understand context, identify threats and opportunities, assess exposure, choose proportionate responses, assign ownership, implement actions and communicate changes.
Executive summary
Five-step procedure
Identify, Assess, Plan, Implement and Communicate form the source risk-management procedure; communication runs throughout.
Threats and opportunities
Risk includes uncertain events with negative or positive effects on objectives.
Context matters
The project should understand organisational risk appetite and its own total exposure before judging individual risks.
Ownership drives action
Each significant risk needs a risk owner; specific response actions may be assigned to risk actionees who work under that owner.
Purpose, definitions and project objectives
The Risk theme is used to identify, assess and control uncertainty so that the project’s ability to succeed is improved. The source defines a risk as an uncertain event or set of events that, if it occurs, affects the achievement of objectives. Risk is therefore not limited to bad events. A threat can damage objectives; an opportunity can improve them.
Risk is assessed through both likelihood and impact. The impact should be linked to project objectives rather than expressed as a vague feeling of severity. A risk may affect time, cost, quality, scope, benefits or other project objectives. The closer the description is to those objectives, the easier it becomes to choose a sensible response.
Risk management is a systematic application of principles, approaches and processes for identification, assessment, response planning, implementation and communication. The supplied material expects the project to work within the organisation’s or programme’s risk-management system rather than invent an isolated method for each project.
Risk Management Approach and Risk Register
The project defines a Risk Management Approach during initiation. At minimum it explains how risks will be identified and assessed, how responses will be planned and implemented, how risk information will be communicated, how risks that may materially affect the Business Case will be handled, and who is responsible for risk-management activities.
The approach should also reflect the organisation’s attitude to risk and may establish a dedicated risk budget. The source describes a risk budget as money ring-fenced to fund specific responses to threats and opportunities, including contingent actions if a risk materialises. A risk budget is not a general reserve to conceal poor estimates; it should be governed according to the stated approach.
The Risk Register records identified threats and opportunities, their status and history, analysis, planned responses and ownership. It is not a one-time workshop output. The source requires risks to be identified, assessed, managed and reviewed throughout the project lifecycle, with lessons used to improve the process.
Risk Management Approach
Defines the project-specific system: procedure, techniques, standards, communication, roles, appetite context and any risk-budget rules.
Risk Register
Maintains the live record of threats and opportunities, analysis, responses, owners, actionees, status and history.
Project context, appetite, exposure and tolerance
Before analysing individual risks, understand the project context. The source suggests considering customer quality expectations, number and relationships of organisations, stakeholder needs, project importance and complexity, delivery approach, assumptions, legislation/governance requirements, corporate policies and whether the project sits inside a programme or portfolio.
Risk appetite is the amount of risk the organisation is willing to accept. Risk exposure is the amount of risk the project requires the organisation to accept. Risk tolerance is a threshold of exposure that may be exceeded only with appropriate approval and that triggers a defined response such as escalation to senior management.
These concepts prevent risk decisions from being made in isolation. Two projects can face the same technical threat but make different decisions because one is business-critical, one has very low appetite for safety or regulatory exposure, or one already carries a high aggregate risk load. The project should therefore evaluate both individual risk significance and the overall exposure profile.
| Concept | Meaning | Management question |
|---|---|---|
| Risk appetite | Amount of risk the organisation is willing to accept. | How much uncertainty is the organisation prepared to carry? |
| Risk exposure | Risk the project requires the organisation to accept. | What is the combined risk burden created by this project? |
| Risk tolerance | Threshold that triggers approval or response when exposure crosses it. | When must this level of management escalate or seek authority? |
Step 1 — Identify
Identification has two parts: understand the context and identify specific risks. The source recommends describing a risk in a cause–event–effect form. The cause is the existing condition or situation that could give rise to uncertainty. The event is what may happen. The effect is the consequence for project objectives.
This structure is valuable because weak statements such as “supplier risk” do not tell management what to do. A stronger statement might explain that a specialist component has one qualified supplier (cause), delivery may be delayed (event), which could postpone integration and increase stage cost (effect). The response can then target the cause, probability or impact.
Identification should cover opportunities as deliberately as threats. A new technology, earlier supplier availability or reuse opportunity may improve cost or time if actively exploited. Record enough information in the Risk Register for someone who did not attend the workshop to understand the uncertainty and its significance.
If the event has already happened, it is generally an issue rather than a risk. Risks are uncertain future events; issues are relevant events or situations that have occurred and require management.
Step 2 — Assess
Assessment first estimates an individual risk’s probability, impact and proximity. Proximity asks how soon the risk may occur if no action is taken and helps prioritise response timing. A distant high-impact threat may require monitoring and early prevention; an imminent medium threat may need immediate action.
The second part is evaluation of overall exposure. The source mentions probability–impact matrices, summary risk profiles and other quantitative or analytical techniques as possible aids. The precise scoring model is not prescribed here; what matters is that the project can rank risks consistently and determine whether aggregate exposure remains within appetite.
Assessment should be revisited when information changes. A risk that initially appears remote can become imminent when a dependency slips. A response may reduce probability but leave impact unchanged. The register should preserve enough history to understand these changes and the basis of decisions.
Step 3 — Plan responses
The source provides response categories for threats and opportunities. For threats, avoid removes the uncertainty by removing its cause, while reduce lowers probability and/or impact. For opportunities, exploit removes uncertainty by making the opportunity happen, while enhance increases its probability and/or benefit.
For both kinds of risk the source includes transfer, share, accept and contingent planning, although it notes transfer is not usually used for opportunities. Transfer allocates financial or delivery exposure to an external party, for example through insurance or outsourcing, but does not necessarily remove all consequences for the commissioning organisation. Share allocates pain or gain collaboratively. Acceptance records that no proactive response will be taken. A contingent plan is prepared for use if the trigger event occurs.
| Response | Typical intent | Important check |
|---|---|---|
| Avoid | Remove a threat and its uncertainty by eliminating the cause. | Is the cost or scope impact of avoidance justified? |
| Reduce | Lower probability and/or impact of a threat. | What residual risk remains after the action? |
| Exploit | Make an opportunity occur. | Is the cost justified by the expected upside? |
| Enhance | Increase probability and/or benefit of an opportunity. | What action actually improves the opportunity? |
| Transfer | Move defined exposure to an external party. | What risk remains with the project despite the contract/insurance? |
| Share | Allocate pain/gain with one or more parties. | Are incentives and responsibilities clear? |
| Accept | Take no proactive action beyond monitoring. | Is acceptance within appetite and authority? |
| Contingent plan | Prepare action that starts if a trigger occurs. | Are trigger, owner, budget and readiness explicit? |
Steps 4 and 5 — Implement and communicate
Response planning has no value unless actions are implemented. The risk owner is accountable for management, monitoring and control of an assigned risk, including implementation of the selected response. A risk actionee performs one or more specific response actions under the owner’s direction. Separating these roles allows one owner to coordinate several actions without personally executing each task.
The project should monitor whether responses are actually reducing or increasing the targeted probability or impact. If not, corrective action or a different response may be needed. Closed risks should not simply disappear; history can become useful lessons for later stages and projects.
Communication is continuous across the procedure. The source identifies Checkpoint, Highlight, End Stage, End Project and Exception Reports as routes through which relevant risk information may be communicated. The level of detail should match the audience. A Project Board needs exposure, trend and decisions; a delivery team needs actionable response tasks and triggers.
Identify
Context plus cause–event–effect risk statements.
Assess
Estimate probability, impact and proximity; evaluate overall exposure.
Plan
Select responses and contingent actions that fit appetite and authority.
Implement
Assign owner/actionee, execute responses and monitor effectiveness.
Communicate
Keep stakeholders informed throughout identification, assessment, response and review.
Practical verification checklist
- Define a Risk Management Approach during initiation.
- Maintain a live Risk Register for both threats and opportunities.
- Understand organisational risk appetite and project context before applying scores.
- Write significant risks using cause–event–effect logic.
- Assess probability, impact and proximity and review aggregate exposure.
- Select threat and opportunity responses deliberately and document residual risk.
- Assign a named risk owner and actionees for response tasks.
- Define triggers, resources and ownership for contingent plans.
- Communicate material risk changes through the appropriate management reports.
- Review risks throughout the lifecycle and use lessons to improve identification and response.
Common mistakes to avoid
- Recording events that have already occurred as risks instead of issues.
- Writing vague labels such as “technical risk” with no cause, event or effect.
- Scoring individual risks without considering aggregate exposure or organisational appetite.
- Treating transfer as if the organisation has no residual consequence.
- Creating response actions with no owner or due date.
- Focusing only on threats and ignoring opportunities.