Most project managers treat the risk management plan as a formality — written once, filed away, never opened again. That is not risk management. That is paperwork.
The risk management plan is a living component of the project management plan. According to the PMBOK® Guide, 8th Edition, risk management activities are structured and performed across the entire project life cycle.
Here is what it actually contains — and when each part comes into play.
Table of Contents
1. Risk Strategy
The first thing to define is the general approach to managing risk on the project. Is the organisation conservative, moderate, or aggressive in how much uncertainty it will accept?
This sets the tone for every decision that follows.
2. Methodology
The methodology defines the specific approaches, tools, and data sources that will be used. This covers three areas:
How risks will be identified — brainstorming, SWOT analysis, checklists, interviews, lessons learned
How risks will be analysed — qualitatively (probability × impact) and quantitatively when the project requires it
How risks will be responded to — for threats: avoid, transfer, mitigate, accept; for opportunities: exploit, share, enhance, accept
3. Roles and Responsibilities
The plan defines who leads, who supports, and who owns each risk management activity. Without this, risk ownership falls through the gaps.
At minimum: a risk lead, risk owners for individual risks, and a sponsor with authority to approve escalations above the defined threshold.
4. Funding
Risk management costs money. The plan establishes two types of reserve:
Contingency reserve — covers identified risks. Held within the project budget.
Management reserve — covers unknown risks (unknown-unknowns). Held above the project budget, released by authorised personnel only.
The plan also defines who can approve the use of each reserve and at what threshold.
5. Timing
This is where most plans fail. The PMBOK® Guide 8th Edition maps six risk processes across the project life cycle:
Process | Phase |
|---|---|
Plan Risk Management | Planning |
Identify Risks | Planning (iterative throughout) |
Perform Risk Analysis | Planning (iterative throughout) |
Plan Risk Responses | Planning (throughout project) |
Implement Risk Responses | Executing |
Monitor Risks | Monitoring & Controlling |
Risk management is not a planning-phase activity. It runs from conception to close.
6. Risk Categories
The plan organises risks into categories to ensure nothing is missed. The PMBOK® Guide 8th Edition uses a Risk Breakdown Structure (RBS) with four top-level categories:
Technical — scope, requirements, technology, interfaces
Management — resourcing, communication, organisational structure
Commercial — contracts, suppliers, client stability
External — legislation, weather, site conditions, regulatory
7. Stakeholder Risk Appetite and Thresholds
Risk appetite is the degree of uncertainty an organisation is willing to accept. The plan records each key stakeholder's appetite — expressed as measurable thresholds around project objectives.
For example: a cost threshold of ±5% of budget reflects low appetite — Medium and above risks require an active response. A threshold of ±20% reflects high risk appetite — only Very High risks escalate.
These thresholds drive how risks are scored and when they escalate.
8. Probability and Impact Definitions
The plan defines what probability and impact mean for this project — not in general terms, but specifically. Use a scale like this as a starting point:
Scale | Probability | Time Impact | Cost Impact | Quality Impact |
|---|---|---|---|---|
Very High | >70% | >3 months | >20% of budget | Deliverable unfit for purpose |
High | 41–70% | 1–3 months | 11–20% of budget | Major rework required |
Medium | 21–40% | 2–4 weeks | 6–10% of budget | Some impact on key functions |
Low | 6–20% | <2 weeks | 1–5% of budget | Minor impact, easily resolved |
Insignificant | <5% | No change | <1% of budget | No functional impact |
Adjust the thresholds to match your project scale and the organisation's risk appetite. The structure stays the same.
The Point
Write it at project conception. Complete it before execution starts. Update it when the project changes. Use it every time you open the risk register.
The document does not manage risk. The discipline of using it does.
P.S. Not sure if you qualify for the PMP? Check the free PMP eligibility tool in under a minute: https://vandersonbaril.com/products/pmp-eligibility-checker
Found this useful? Share it with a colleague. A clear process saves more time than any tool.
Thanks for reading.
See you next Saturday!
