PMP Risk Management: Plan, Register, Analysis and Responses

Project risk management is the work of finding, analyzing, responding to and monitoring uncertainty that could affect a project's objectives, so that threats are reduced and opportunities are captured before they happen rather than after. A risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more objectives. Negative risks are threats; positive risks are opportunities. Both are managed through the same process.

Two levels of risk matter, and exam scenarios often turn on which one is in play:

• Individual project risks: specific uncertain events, such as a supplier strike or a failed integration, each recorded in the risk register with its own owner and response.
• Overall project risk: the effect of all uncertainty on the project as a whole, such as the chance of finishing by a date or within a budget. It can be high even when no single risk is, because many moderate risks add up.

The PMP Examination Content Outline (July 2026) places this as Task 5 of the Business Environment domain, "Plan and manage risk", with seven enablers that this lesson follows:

1. Develop a risk management plan: agree how risk will be handled before identification starts.
2. Identify risks: find threats and opportunities widely and continuously.
3. Analyze risks: prioritize them qualitatively, and quantify overall exposure where it is warranted.
4. Maintain a risk register (the outline's example is poor IT security): keep entries specific, owned and current.
5. Execute a risk management plan (examples: risk responses for security and managing sustainability risks).
6. Monitor and control risks: review, close, add and audit.
7. Communicate the status of a risk impact on the project to the people who need to decide.

Neighbouring tasks own the related work: what happens once a risk has occurred and become an issue is covered in the impediments and issues lesson, baseline changes in the change control lesson, and the sizing of contingency and management reserves in the cost lesson. This lesson touches them only where a risk decision depends on them.

The risk management plan describes how risk will be managed on this project; the risk register records each risk. The plan is written first, so that everyone rates, owns and reports risks the same way, and it is a component of the project management plan.

Tailor the plan to the project

Every project needs an agreed approach to risk, but its size should fit the project. The test is whether the plan gives everyone agreed rating scales, named owners, an escalation path and a review rhythm; on a low-complexity project that can be a page or two, often reviewed inside existing team events, while a complex, regulated programme needs far more. Detail beyond what the project will use adds cost without reducing risk. The team should help write it, because it is the team that will use it.

Appetite, thresholds and tolerance

Risk appetite is how much uncertainty the organization and its stakeholders are willing to accept in pursuit of the project's objectives. The plan turns appetite into measurable risk thresholds, for example "at least 70% confidence of opening by the launch date" or "zero tolerance for anything that could cause a safety injury". Thresholds decide which risks need active responses, and two rules follow from that:

• A specific threshold overrides a generic score. If the plan sends low-scoring risks to the watch list but also states zero tolerance for a kind of outcome, a risk that would cause that outcome needs an active response even when its matrix score is low.
• Overall thresholds are judged on overall risk. If a simulation shows the project falls short of a confidence threshold, the project manager plans responses to overall project risk and agrees them with the sponsor, even though no individual risk ranks high. The inputs to the model should reflect honest estimates; the response changes the project, not the analysis.

Risk identification finds the threats and opportunities that could affect the project and records them in the register. It starts early, involves the team and stakeholders rather than the project manager alone, and continues for the whole project, because new risks keep emerging.

Identification techniques find risks. A probability and impact matrix, sensitivity analysis and a risk audit do something else (prioritize, quantify, evaluate the process), so they are not the right tool when the need is to surface uncertainties nobody has listed yet.

The three-part risk statement

A good register entry states the cause, the uncertain event and its effect on objectives, often in the form "Because of cause, event may occur, which would lead to effect". For example: "Because the test laboratory is shared by three projects, it may be unavailable when system testing is due, which would delay go-live." Each part has a job: the cause shows where a response can act, the event is what the owner watches for, and the effect sizes the impact. An entry missing any part is hard to rate, own or respond to.

Risk, issue or cause?

• A risk has not happened and might not happen.
• An issue is something that has already happened or is certain. It goes to the issue log and is resolved, not rated for probability.
• A certain fact can still be the cause of new risks. If a regulator has already published a new reporting rule, the rule is a fact, not a high-probability risk; what remains uncertain is what it leads to (rework of reports, a missed compliance date, extra audit effort). Those uncertain events, with the rule as their cause, belong in the register.

Risk analysis decides which risks deserve attention and how much uncertainty the project carries overall. Qualitative analysis is done for every identified risk; quantitative analysis is done only where it is worth the effort.

Qualitative analysis

Qualitative analysis rates each risk's probability and impact on the scales defined in the risk management plan, then ranks risks on the probability and impact matrix. Other factors refine the order: urgency (how soon a response is needed), proximity, and how manageable the risk is. It is fast and cheap, which is why it is the first step when many risks compete for limited response effort.

Before acting on a rating, check its risk data quality: how accurate, reliable and complete the information behind it is. A rating built on thin or unsupported information can push a risk to the top of the list and trigger costly responses. Low-quality data is improved before decisions rest on it; a rating is only as trustworthy as the evidence and judgement behind it, and changing the number without changing the evidence leaves the quality where it was.

Risks that rate low are not deleted. They go on the watch list in the register and are re-rated at risk reviews, because conditions change.

Quantitative analysis

Quantitative analysis numerically estimates the combined effect of risk on project objectives. It needs good data and a model (a resource-loaded schedule or a cost estimate with ranges), so it is used on large or complex projects, for overall project risk, or for a few critical risks. Choose the tool by the question being asked:

A three-point (PERT) estimate of the critical path also produces a probability, but it covers only one path. Where several paths are close to critical, delays on them combine at the points where they merge (merge bias), and discrete risk events are left out, so a single-path figure is optimistic. A simulation of the whole schedule with the registered risks mapped to activities avoids both gaps.

A risk response is the action chosen to deal with a risk, and the best one balances the cost and effort of the response against the exposure it removes and the value it protects. PMI's standard strategies come in matching pairs:

Points that decide most strategy questions:

• Transfer does not remove the threat. An insured shipment can still be lost; a performance bond does not make a contractor finish on time. The project still monitors the risk.
• Exploit, enhance and share differ by certainty. Only exploiting removes the uncertainty; an incentive (enhance) or a benefit split (share) leaves the outcome uncertain. If the sponsor wants an opportunity secured, that points to exploit.
• Several strategies are often workable, so compare cost against exposure. When a threat would arrive with notice (an announced retirement, a lead time), active acceptance with a trigger can beat expensive mitigation now, because value is delivered today and the plan is ready when needed. When the threat would hit without warning or breaches a threshold, act now.
• Overall project risk has its own responses: avoid (for example by rescoping), exploit, transfer or share, mitigate or enhance (re-sequencing, changing the delivery approach), or accept, agreed with the sponsor.

Escalation

Escalate a risk when its cause or the response to it lies outside the project's scope or the project manager's authority, for example a possible change to a corporate procurement policy that would affect every project in the division. A project-level response cannot reach a cause the project does not control. The project manager identifies who should own it and passes it to them (program manager, portfolio manager or business owner). Once that owner accepts it, the project's register keeps the entry for traceability, marked as escalated with the receiving owner noted, and the project team stops monitoring it and planning responses.

Escalation is not a reflex for anything uncomfortable: a risk the project can respond to itself, even a serious regulatory one, stays with the project.

Executing the risk management plan means carrying out agreed responses when they are due, through the risk owner, within the approvals the plan sets. Planned responses only help if someone acts on them.

• Risk owner: the named person accountable for monitoring a risk and carrying out its response. "The team" is not an owner.
• Trigger: the warning sign that a risk is about to occur or has occurred, such as a vendor's quality report showing rising defect rates or a key indicator crossing a limit set in the plan.
• Contingency plan: the planned response carried out when the trigger occurs (part of active acceptance or a backup to another response). When the trigger fires, the owner runs it: the response was prepared and approved for exactly this case. If the event has occurred, it is now an issue and is managed as one.
• Fallback plan: a second planned response used if the contingency plan proves ineffective. Switching to it when the first response is not working is executing the plan, not improvising.
• Workaround: an unplanned response to a risk that was never identified, or was passively accepted, and has now occurred. There is no contingency to activate, so the project manager acts within their authority to keep work going, then records the event, updates the register and checks for related risks.

Funding and approvals still apply

The contingency reserve is held for identified, accepted risks. Spending it as the plan provides for a registered risk is executing the plan, not changing the baseline, so it does not need the change control board. But a contingency still follows the approval rules the plan sets: if the plan says a costly switch needs sponsor approval, the risk owner cannot start it alone, and the project manager seeks that approval promptly. Work outside the approved reserve or baseline goes through change control.

Residual and secondary risks

Adding a second supplier to reduce delivery risk, for example, may create a secondary risk of inconsistent quality between the two sources. A transfer creates a secondary risk too: the party that took it on may be unable to pay or perform. Because transfer never removed the underlying threat, the original risk stays open, and the chance that the transfer fails is analyzed and given a response of its own.

Maintaining the risk register means keeping every entry specific, owned and current, so the register reflects the project's real exposure today. The outline's example, poor IT security, shows the commonest failure: an entry that is only a broad label, owned by a group and answered with a general intention, cannot be acted on. A usable entry names the cause and the uncertain event (for example, because build servers run an unsupported operating system, an attacker could alter released code, which would expose customers), a named owner, the trigger that signals it, the response actions and their status. What makes an entry usable is its content, not its score or which register holds it.

A typical register entry holds the risk ID and statement, category, probability, impact and priority, urgency, owner, triggers, response strategy and actions, contingency and fallback plans, residual and secondary risks, and status (open, escalated, occurred, closed).

Monitor and control: reviews versus audits

Monitoring risks means tracking identified risks, watching residual risks, identifying new ones and checking that responses work, throughout the project. Two activities are easy to confuse:

Routine register updates (closing a risk whose window has passed, adding a new one) do not need a change request or sponsor approval. Other monitoring inputs include reserve analysis (is enough contingency left for the remaining risk?) and work performance data such as variance and trend.

Agile delivery manages risk by learning early and reviewing it often, rather than through a heavy upfront phase. The same principles apply (identify, analyze, respond, monitor), but they run in the team's cadence.

• Risk-adjusted backlog: risk-reduction work is ordered alongside features by value and exposure. Reducing a large uncertainty early can be worth more than a feature of similar size, because the cost of a wrong assumption grows with every iteration built on it.
• Spikes: short, time-boxed experiments that answer a technical or product question (will this framework meet accessibility needs? can the chosen data store return results fast enough?) before the team commits to a design.
• Cadence: risks are raised at daily stand-ups, considered in iteration planning, checked at reviews with stakeholders and improved at retrospectives.
• Visibility: a risk board or risk burndown makes exposure visible to the team and stakeholders.
• Frequent delivery of working increments is itself a risk response: it exposes misunderstandings and integration problems while they are cheap to fix.

The test for any agile risk practice is whether it brings the answer to the biggest uncertainty sooner; practices that defer learning or hide exposure behind buffers increase risk in an agile context. In hybrid projects, predictive components (contracts, construction, regulated releases) keep a formal register and thresholds while adaptive components work through the backlog; both feed one view of project risk.

Security and sustainability risks are managed through the normal risk process: identified before they occur, written as specific statements, owned, and given responses that address the real exposure. The outline calls out both as examples of executing the risk management plan.

Security risks

• Risk or issue? A weakness that has not yet led to exposure, such as a planned test environment that would copy production data without masking it, before any copy has been made, is a risk. Register it with an owner and respond before it can become an issue.
• Threshold first. Where the plan states zero tolerance (for example for known critical vulnerabilities in production), acceptance and transfer are ruled out while the exposure exists. Insurance pays for a breach; it does not prevent one.
• Prefer the narrowest effective avoidance. When avoidance is warranted, change only as much of the plan as the exposure requires, so the rest of the value still reaches customers. Avoided risks stay in the register with an owner and a trigger for revisiting the decision.

Sustainability risks

Sustainability risks cover environmental, social and climate-related uncertainty that affects the project or the life of its product, such as heatwaves degrading materials, water scarcity, rising energy costs, or failing the organization's sustainability commitments. Two points matter:

• Look at the exposure period. A heat or water risk to a plant lasts its operating life, so a response that only covers the delivery period misses most of the exposure.
• Respond while the design is open. Mitigating through design (specifying heat-tolerant materials, water recycling, lower-energy systems) is far cheaper before the design is final than after handover. External causes are often beyond control, but their effects on the product usually are not.

Scanning for new regulations, market shifts and similar external changes belongs to the external business environment task; once such a change creates uncertainty for this project, it enters the register like any other risk.

Communicating risk status means telling the people who need to know where risk stands, what it could do to the project's objectives and what decisions are needed, in a form and at a time that lets them act. It is tailored to the audience, as set out in the risk management plan's reporting section and the communications plan.

• For senior decision-makers (sponsor, steering committee): overall risk exposure and its trend, the main reason it changed, the forecast effect of key risks on objectives, and the decision or approval being requested. Detail beyond that belongs in the team's records, not the decision-maker's limited time.
• For the team: the detailed register or risk board, owners, triggers and upcoming responses.
• Timing follows the risk, not the calendar. When a decision is needed before the next scheduled report, the decision-maker hears about it in time to make it; the reporting calendar is a minimum, not a gate.
• Be honest about the data. Do not reassure a sponsor on the strength of a vague register entry; fix the entry first, then report what is really known.

Common formats include a summary of overall exposure (for example the confidence of meeting a date or budget from the latest simulation), a heat map of top risks, a risk trend or burndown, and a short list of decisions required.