Ask most experienced project managers what M_o_R actually is, and you tend to get a version of the same answer. Isn't that the risk bit from PRINCE2, with its own exam attached. It's a fair guess. PRINCE2 has a risk theme. MSP builds risk into its governance structure too. Most people meet risk management for the first time inside one of those frameworks, so when a separate qualification called Management of Risk turns up on a training provider's list, it can look like the same content, repackaged, with an extra fee attached.
That assumption survives longer than it should, partly because the framework's name does it no favours. Call something Management of Risk and people picture a spreadsheet, a five by five matrix, a register somebody updates before a steering board meeting. Reasonable enough as a mental model. It's also not what the framework actually is.
M_o_R exists at a different altitude to PRINCE2 or MSP. It was developed in 2002, prompted by the Turnbull Report on corporate governance and its requirement that UK listed companies show a proper internal control framework, including how they handled risk. That origin matters, because it means M_o_R was never built as a project method's risk chapter. It was built as a governance discipline that a project method's risk chapter could plug into. PRINCE2 tells you how to run risk management inside a single project. M_o_R tells you how an organisation ensures that risk gets identified, escalated and acted on consistently, whether the activity in question is a single project, a whole portfolio, or the day to day running of the business.
The distinction became a practical one on a course a while back, with a delegate who'd already passed PRINCE2 Practitioner and MSP Foundation and was doing M_o_R mainly because his employer required it for a PMO role. He spent the first morning fairly openly unconvinced. By the afternoon, working through a scenario where a risk identified at project level needed escalating to a portfolio board that used entirely different appetite thresholds, the gap became obvious to him without anyone needing to argue him into it. His project method had told him how to log the risk. It hadn't told him how the organisation was meant to decide who owned it once it moved beyond his project's boundary. That's the layer M_o_R sits in, and it's genuinely missing from PRINCE2 and MSP on their own.
The current version is the fourth edition, published as Management of Risk: Creating and Protecting Value, publicly available since late 2022. It replaced the third edition from 2009, and the change is bigger than a cover refresh.
The clearest shift is structural. Earlier editions organised the framework around four perspectives: strategic, programme, project and operational. Version 4 introduces a sixth, splitting programme-level risk into portfolio and programme separately, and adding a dedicated product perspective. That last one is the tell for who this rewrite was actually aimed at. Product delivery, in the Agile, continuously-shipped sense, doesn't map cleanly onto a project with a defined start and end, and the third edition had no natural home for the risk conversations that happen inside it. Version 4 gives it one, explicitly, which is a meaningful concession from a framework whose roots are firmly plan-driven.
The process side changed just as much, if less visibly. Third edition risk management ran through four steps, identify, assess, plan, implement, each with sub-tasks folded inside it. Version 4 breaks that same territory into eight distinct processes, giving separate, named weight to activities like identifying context and identifying risks, rather than treating them as sub-steps of a single "identify" stage. It reads as more granular on paper. In practice it makes the framework easier to tailor, because an organisation can adopt or skip individual processes rather than inheriting a four-step block as one unit.
The eight principles haven't moved. Seven remain enablers, aligns risk with objectives, engages stakeholders, provides clear guidance, informs decision making, and so on, with the eighth, achieving measurable value, standing as the outcome the other seven are meant to produce. What has changed is how explicitly the guidance ties those principles to opportunity rather than just downside protection, and how much more space it gives to people, culture and cognitive bias in why risk management actually breaks down in practice. Most failures aren't caused by a missing process step. They're caused by a project manager who doesn't want to be the one raising the awkward risk at the board meeting.
Even the exam changed shape. Third edition Practitioner was a scenario paper, four questions worth twenty marks each, three hours, written response. Version 4 replaced it with an open-book objective test, sixty five questions across standard and matching formats, two hours fifteen minutes, pass mark fifty percent. It's a faster, more consistent way to assess the same competence, and it brings M_o_R in line with how PeopleCert now runs most of its other Practitioner exams.
None of this makes the third edition obsolete overnight. PeopleCert still runs both. But an organisation building its risk capability from scratch, or a practitioner deciding where to spend their next certification, is choosing version 4 for a reason. It's the edition built for how delivery actually looks now, project and product, plan-driven and iterative, sitting inside one organisation rather than two separate worlds. If you're weighing up where M_o_R fits alongside the frameworks you already hold, get in touch about your PMP training options and we can talk through what it would actually add.
Andre Malowney is a project management trainer accredited across PMI, APMG, APM and PeopleCert frameworks, working with both traditional plan-driven practitioners and Agile delivery teams. Find him on LinkedIn: www.linkedin.com/in/andremalowney.