III.5 — Plan and Manage Risk
III.5 · Last updated: 11/10/2026
Risk gets a new home and seven enablers
III.5 — Plan and Manage Risk is the fifth task in the Business Environment domain of the 2026 ECO, and that domain carries 26% of the exam. With seven enablers it is one of the two widest tasks in the domain; only III.2 — Plan and Manage Project Compliance has as many. The ECO lists them as follows:
- Identify risks
- Analyze risks
- Monitor and control risks
- Develop a risk management plan
- Maintain a risk register (e.g., poor IT security)
- Execute a risk management plan (e.g., risk response for security and managing sustainability risks)
- Communicate the status of a risk impact on the project
The list matches the processes of PMBOK® 8's Risk performance domain almost one for one. The Guide describes that domain as a comprehensive approach to creating project resilience through risk management practices, one that calls for planning ahead for identified risks and also for adapting through flexible response mechanisms when risks do occur (PMBOK® 8, Guide p.92).
🔴 II.3 is no longer the number for risk
| 2021 | 2026 | |
|---|---|---|
| Number | II.3 | III.5 |
| Domain | Process | Business Environment |
| Title | Assess and manage risks | Plan and manage risk |
In 2021 risk was the third task of the Process domain. In 2026 both its number and its domain changed, and the number II.3 went to II.3 — Help Ensure Value-Based Delivery. If an older source shows a risk question tagged "II.3", that source was tagged against the 2021 outline. These shifts are collected in what changed in the 2026 PMP exam.
The verb in the title changed as well. With plan in place of assess, the emphasis moves from evaluating risks one by one toward setting up, in advance, how the project will approach risk. The enabler list shows the same thing, since developing the risk management plan and executing it appear as two separate items.
The approach comes before the risks
According to the Guide, planning risk management should begin as soon as the project is conceived and be completed early in the project (PMBOK® 8, Guide p.95). Its output, the risk management plan, is a component of the project management plan and describes how risk activities will be structured and carried out. The elements it may contain include the overall risk strategy, the methods and data sources to be used, roles and responsibilities, the funding needed for risk activities, when and how often risk processes will be performed, and the risk categories (PMBOK® 8, Guide pp.134-135). The funding element also sets the rules for using the contingency reserve and the management reserve.
The most tested element of the plan is stakeholders' risk appetite. The Guide asks for the risk appetite of key stakeholders to be recorded in the plan and expressed as measurable risk thresholds for each project objective (PMBOK® 8, Guide p.136). It illustrates the link between appetite and threshold with an example, in which a threshold of ±5% around a cost target reflects a lower risk appetite than a threshold of ±10% (PMBOK® 8, Guide p.94). When a question asks whether a given variance is acceptable, those thresholds are what the answer rests on.
Identifying and analyzing risks
The Guide defines a risk as an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more objectives. Negative risks are usually called threats and positive ones opportunities, and a risk can be described with a cause, event, and effect structure (PMBOK® 8, Guide pp.92-93). That definition already makes clear that risk management covers more than warding off bad outcomes, so an answer option that aims to enlarge an opportunity is not wrong for that reason alone.
The Guide stresses two points about identification. Real risks have to be separated from concerns and from issues, and the initial identification is never complete, which is why the process repeats throughout the project (PMBOK® 8, Guide pp.95-96). The Guide's four-box classification supports the same separation (PMBOK® 8, Guide p.93, Figure 2-46):
| Class | What it means in the Guide |
|---|---|
| Known-known | Facts and requirements; managed as part of scope and not counted as risk |
| Known-unknown | Classic risk; information exists to determine probability and impact |
| Unknown-known | Hidden fact; the knowledge exists in the community but not with those doing the work |
| Unknown-unknown | Emergent risk; the knowledge lies outside the sphere of influence |
Analysis is iterative too, and it combines qualitative and quantitative actions. Qualitative analysis continues throughout the project and assesses individual risks by their probability of occurrence and their impact. Quantitative analysis is not needed on every project, and when it is used it examines numerically the combined effect of identified risks and other sources of uncertainty on the project objectives (PMBOK® 8, Guide p.96). The exam usually probes the difference this way. If you have a list of risks to prioritize, qualitative analysis applies, and if you need to put a number on the total effect on the project as a whole, quantitative analysis does. Risks that come out low in probability and impact are not deleted either; the Guide suggests keeping them on a watch list in the risk register for future monitoring (PMBOK® 8, Guide p.195).
The risk register and the risk report
The ECO's enabler about maintaining a risk register looks at a single document, while the Guide describes two together. The risk register is defined as the place where the outputs of the risk processes are recorded. The details of individual risks are kept there, and the results of identification, analysis, response planning, response implementation, and monitoring are entered into it as the project moves on. It may also hold potential risk owners, potential responses, triggers that signal a risk is approaching, and timing information (PMBOK® 8, Guide p.137). The risk report, for its part, presents the sources of overall project risk and summary information about identified risks, such as how many threats and opportunities were found and how the risks are distributed across categories (PMBOK® 8, Guide p.138).
The ECO's example for the register, poor IT security, also has a counterpart in The Standard. The book says that information security threats and cybersecurity concerns grow as technology advances, and that working in alignment with the organization's information technology unit to protect project information is a responsibility of the project management team and the project manager (PMBOK® 8, Standard p.32).
Planning and executing responses
The Guide lists response strategies separately for threats and for opportunities. For threats it offers escalate, avoid, transfer, mitigate, and accept, and for opportunities escalate, exploit, share, enhance, and accept (PMBOK® 8, Guide p.94). Escalation fits when the team or the sponsor finds that a threat lies outside the project scope or that the proposed response would exceed the project manager's authority, and once a threat has been escalated the team no longer monitors it (PMBOK® 8, Guide pp.203-204).
The response planning process allocates resources or adds reserves where needed and inserts new activities into project documents (PMBOK® 8, Guide pp.96-97). Which risks the reserves cover is a frequent exam topic. The contingency reserve is the budget allocated for identified risks, and the Guide mostly treats it as the allowance meant to address known-unknowns (PMBOK® 8, Guide p.192). The management reserve is held to cover unknown risks (PMBOK® 8, Guide p.102). One detail that PMBOK® 8 brings in deserves attention here. The management reserve always stays outside the cost baseline. For the contingency reserve, the book gives two scenarios, and depending on the organization's preference it may sit inside the cost baseline or be kept outside it (PMBOK® 8, Guide pp.60-61). The budget side of reserves is covered in detail in II.6 — Plan and Manage Finance.
The implementation process makes sure the agreed responses are carried out as planned (PMBOK® 8, Guide p.98). Its outputs include change requests, so a response that touches a baseline goes through the process described in III.3 — Manage and Control Changes (PMBOK® 8, Guide p.100).
Monitoring risks and reporting their status
The monitoring process covers tracking the implementation of response plans, following identified risks, identifying and analyzing new risks, and evaluating how effective the responses are. The Guide adds that the process also keeps risk owners assigned (PMBOK® 8, Guide p.98). Adaptive projects do this more often. In the Guide's agile example, the team repeats its risk assessment at the start of every sprint, beyond the one it did at the outset, and holds risk review meetings with stakeholders at the end of each iteration (PMBOK® 8, Guide p.101).
The ECO's last enabler asks you to communicate the status of a risk's impact. The Guide sees stakeholders as critical sources of information about risk and uncertainty, and says effective stakeholder engagement can keep the risk processes aligned with stakeholder expectations (PMBOK® 8, Guide p.101). Among the tailoring considerations it also lists keeping communication open with the relevant stakeholders while responses are adjusted flexibly (PMBOK® 8, Guide p.99). The written vehicle for that communication is often the risk report described above.
Sustainability risks
The ECO's sustainability example rests on a definition in The Standard. According to the book, sustainability risks arise when project activities fail to balance or integrate social, economic, and environmental concerns. Its examples include putting cost ahead of environmental responsibility, failing to account for community impacts, and underestimating regulatory compliance requirements tied to sustainability (PMBOK® 8, Standard p.51). That last example shows where risk meets compliance, and it links the two tasks.
When a risk materializes
The Guide separates risk from issue by time. An issue is a condition that has occurred or is still ongoing, while a risk describes a possible future problem that has not yet happened, and an issue often grows out of a poorly managed risk (PMBOK® 8, Guide p.93). Recognizing the moment a risk turns into an issue is an enabler of a different task in the ECO, III.4 — Remove Impediments and Manage Issues.
The same page also defines overall project risk, the effect of uncertainty on the project as a whole. Its responses are the same as those for individual threats and opportunities, but they are applied to the whole project and not to a particular event. The Guide adds that when overall risk is too high, the organization may choose to cancel the project (PMBOK® 8, Guide p.93).
About the citations
Every page number above refers to the PMBOK® Guide, Eighth Edition (PMBOK® 8); references to the 2026 ECO are marked "ECO" separately.
⚠️ PMBOK® 8 contains two separate books in one volume, and their page numbering is independent:
- The Standard for Project Management — cited as Standard p. X
- A Guide to the Project Management Body of Knowledge — cited as Guide p. X
This page cites both books; which number belongs to which book is stated in every citation. The numbers are the books' printed page numbers.
This page describes the book; it does not replace it.
