Project risk management process flowchart (register to closure)
Project risk management process flowchart: log the risk, assess probability and impact, escalate, choose a response, review it, and close it or raise an issue.
How it works
Rename the lanes to your governance
Replace Project team, Risk owner, Project manager, Steering group and PMO with the roles and bodies you actually have. Keep the risk owner separate from the project manager: one carries the risk, the other runs the process. If there is no PMO, merge that lane into the project manager rather than leaving a body in the chart that never does anything, and if your steering group and sponsor are the same person, say so.
Write the escalation threshold as figures
"Above the escalation threshold?" is inert until you attach numbers. Most projects set a cost figure tied to the project manager's delegated spend limit and a schedule figure tied to float or a contractual milestone, then treat whichever is breached first as the trigger. Add a route that ignores the score entirely for safety, legal, regulatory or reputational exposure, because those escalate on their nature rather than their rating.
Set the register's mandatory fields
Decide what "Log the risk in the register" has to capture: cause, event and effect as separate fields, the date raised, the proposed owner, the affected work package or milestone, probability and impact with the date they were scored, the chosen response, the actions with dates, and the current status. Anything left optional will be blank within a month, and a risk written as three words cannot be re-assessed by anyone who was not in the room.
Fix the review cadence and the out-of-cycle triggers
The loop only turns if there is a scheduled review. Tie it to the project's existing reporting rhythm rather than inventing a new meeting, review higher-scored risks more often than the rest, and name the events that pull a re-assessment forward: a supplier change, a missed milestone, a new dependency, a scope change, an incident, or a mitigation action slipping. A register touched only before the board pack is accurate one day a month.
Make the mitigation actions real
"Assign actions with owners and dates" means one named person per action, a due date, and a line in the project plan with the effort in it. Actions that live only in the risk register compete with the work everybody is measured on and lose. Track them where the team already looks, and let the risk owner report progress at the review rather than reporting that the risk is unchanged.
Agree the risk-to-issue rule, then publish a version
Define what counts as materialised, who may declare it without waiting for a meeting, and how the cross-reference is carried both ways so the history survives the conversion. Then walk the finished chart through with the project manager, a risk owner and whoever chairs the steering group, correct it to what they actually do, and publish that revision while keeping the earlier ones, so anyone opening it later can tell which version they are reading.
Frequently asked questions
What are the steps in a project risk management process?
Identify the risk, log it in the register with its cause and effect, get a named owner to accept it, assess probability and impact, decide whether it breaches the escalation threshold, choose a response from avoid, reduce, transfer and accept, assign mitigation actions with owners and dates, re-assess it at every review, convert it to an issue if it happens, and close it once its window has passed. Methods use different vocabulary for the same spine — PRINCE2 describes a risk management procedure running from identify and assess through planning and implementing responses, with communication alongside, and the earlier process-based editions of the PMBOK Guide separated planning a response from implementing it and monitoring it. The part that fails in practice is rarely the list. It is the loop back to re-assessment.
What is the difference between a risk and an issue?
A risk is uncertain: it may or may not happen, so it is described as cause, event and effect and carries a probability. An issue has already happened or is now certain. They are managed differently, which is why the distinction is worth enforcing. A risk gets a response strategy and mitigation actions before the event; an issue gets containment, a recovery plan and often a change request for the time or money it consumes. Keeping both in one list fills the register with things that can no longer be mitigated and buries the genuinely uncertain items. In this chart the conversion is an explicit branch: "Risk materialised?" raises a project issue, the register entry closes as materialised, and the cross-reference is carried both ways.
What are the four risk response strategies?
Avoid, reduce, transfer and accept. Avoid removes the cause, usually by changing scope, sequence or approach, and it is the only one that takes the risk off the register rather than shrinking it. Reduce lowers probability, impact or both, and is where most mitigation actions land. Transfer moves consequence to another party through a fixed-price contract, a liability clause or insurance, and it is the option most often overstated: it typically shifts financial consequence and leaves the delivery consequence with the project. Accept means carrying the risk knowingly, with a named approver, a contingency allowance and a review date — a risk nobody funded is not an accepted risk. If your method treats opportunities as positive risk, they have mirror responses: exploit, enhance, share and accept.
Who should own a risk on a project?
One named person, close enough to the cause to notice it changing and senior enough to do something about it. In practice that is usually a workstream, technical or supplier lead rather than the project manager, who owns the process rather than every entry in it. Two patterns cause most of the trouble: ownership assigned to a team or a department, where nobody re-assesses it because nobody in particular was asked to, and every risk owned by the project manager, which turns the register into a personal to-do list that stops being scored. This chart makes "Accept ownership of the risk" a step of its own before assessment, because an owner who has never agreed to be one will not turn up to the review.
How is this different from a risk assessment process flowchart?
They cover different ground. A risk assessment process flowchart is the method: how criteria and scales are agreed, how risks are described, how inherent and residual scores are produced, how existing control effectiveness is judged, and how a treatment is selected. It is written once and applies across the organisation. This page is the project-level operating cycle that consumes those scales — raise, log, own, assess, escalate, respond, act, review, convert or close — over the life of one project, with a steering group, a PMO and an issue log in it. If you are defining how risks are scored, use the risk assessment process template. If you are defining how your project runs its register week to week, use this one.