Planning Risk Responses: Match the Response to the Risk

Open a mature risk register on almost any project and a pattern tends to appear in the response column. Most threats are marked "mitigate", a few say "transfer" because a contract clause happens to exist, and a surprising number simply read "monitor", which describes attention rather than action. The strategy categories are rarely the problem. Most project managers can recite them. The difficulty lies in choosing between them, because a response label that looks complete in a register can leave the actual exposure almost untouched.

The practical answer to choosing a risk response strategy is that the risk should do the choosing, not the list. A response fits when it acts on whatever is driving the risk, sits with someone who can genuinely influence that driver, costs less than the exposure it reduces, and can be put in place before the opportunity to act has passed. Once those four things are clear, the strategy label usually becomes obvious. Start from the label instead, and teams tend to pick whichever option their organisation habitually uses.

Four questions that decide the response

The vocabulary most project managers learn is compact. For threats, the usual options are to escalate, avoid, transfer, mitigate or accept. For opportunities, they are to escalate, exploit, share, enhance or accept. Each describes a different relationship between the project and the uncertainty, so a sensible choice depends on understanding the risk before comparing options. Section 2.7.2 of the PMBOK® Guide, Eighth Edition, places Plan Risk Responses within the Risk Performance Domain, and like the Guide's other processes it is framed as nonprescriptive. That framing is helpful: the process exists to organise these decisions, not to guarantee that every register row carries one of a fixed set of words.

The first question is what is actually driving the risk. "Supplier may deliver late" describes a consequence, not a cause. The cause might be a supplier unfamiliar with the part, a design that has not yet been frozen, or a single machine producing for several customers at once. A response that reduces probability has to touch the cause, while a response that reduces impact works on the consequence, perhaps through buffer stock or resequenced work. Both are legitimate, but the team should know which one it is doing, because they fail in different ways.

The second question is who can influence it. Where the driver sits outside the project's authority, or the consequence reaches beyond the project into a programme, portfolio or customer relationship, escalation is often the matching response. Escalation in this sense hands ownership to the level that can act, and it is not complete until that level has accepted it. Forwarding an email about a risk is not escalating it. Equally, escalating a risk the project could handle perfectly well simply pushes work upwards and weakens the team's standing.

The third question is what the change is worth. A response is proportionate when its cost, including effort, delay and disruption, is sensible against the exposure it reduces and sits within the thresholds agreed in the risk management plan. An expected value comparison can support this as a decision aid, though it never tells you what will happen. The fourth question is when the chance to act closes. Avoidance, which changes the plan so the threat cannot arise, is often available only before a design, contract or approach has been committed. Some mitigations need lead time before they take effect. A risk identified in week two and addressed in week twenty may have far fewer workable responses than it once did, which is why a good response states not only the action but the date by which it must happen.

When transfer moves the money but not the problem

Consider an aerostructures company building fuselage sections for an airframer, with delivery slots on the customer's final assembly line fixed months in advance. During planning, the project moves machined frame brackets to a new supplier offering a better unit price. The risk is logged as the new supplier's first-article parts failing inspection and delaying bracket supply. The response column reads "Transfer: late-delivery penalty included in supply contract", and the register looks finished.

When the project manager works through the four questions, the picture changes. The driver is the new supplier's inexperience with these specific bracket geometries and inspection requirements, which a contract clause does nothing to alter. The consequence that matters is not a financial loss the penalty might recover; it is a missed slot on the customer's line, with commercial and reputational effects far larger than the clause is worth. A penalty clause would compensate the programme for a late bracket. It would not put a single bracket on the aircraft.

The response the team eventually chose combined several elements, each aimed at something specific. To reduce probability, first-article inspection was brought forward and a small early order was placed for the three most complex geometries, so any problems would surface while there was still time to act. To reduce impact, the previous supplier agreed to keep its tooling available for a defined period as a fallback, at a modest cost. Because the slot commitment belonged to the commercial relationship with the airframer, the residual exposure was escalated to the programme director who owned that relationship and approved the fallback budget. The penalty clause stayed in the contract as a useful secondary layer, but nobody described it as the response any longer.

Two further details made the plan usable rather than decorative. Every action had a named owner and a trigger date, including the date on which the fallback arrangement would be released if first articles passed. The team also recorded the secondary risk its own response created: keeping the incumbent's tooling in reserve could signal a lack of confidence to the new supplier at the start of the relationship, so the arrangement was explained to them openly rather than discovered.

Acceptance, opportunities and "monitor"

Acceptance is often treated as the response chosen when the team has run out of ideas. Handled deliberately, it is frequently the most mature choice available. Active acceptance means the exposure is understood, sits within tolerance, and is backed by a contingency reserve or a contingency plan with a clear trigger. Passive acceptance means the risk is acknowledged and revisited without advance provision. Both can be sound, provided the decision was made rather than defaulted into. "Monitor", on the other hand, is not a response at all. Every risk should be monitored; writing it in the response column usually signals that the choice has been postponed.

Opportunities deserve the same discipline and seldom receive it. Exploiting an opportunity means acting to make the beneficial outcome certain, enhancing means increasing its likelihood or effect, and sharing means bringing in a partner better placed to realise it. In the bracket example, early first-article success would have created a chance to pull a later section's build forward and relieve a congested month on the shop floor. An opportunity with no owner, trigger or plan behaves exactly like one nobody identified.

The delivery approach changes the shape of a response more than its logic. In predictive work, responses often live in the integrated plan as scheduled activities, contract terms and budgeted reserves, and avoidance may require a formal change to the baseline. In adaptive work, many responses become work items themselves: a spike to test a technical assumption, an early increment released to real users, or a backlog ordered so the riskiest assumptions are tested first. Short iterations also shorten response windows and create frequent points to reassess. Hybrid projects often need both at once, perhaps contractual protection in a supplier workstream alongside iterative learning in a software workstream, and the project manager's job is to make sure those responses reinforce rather than contradict each other.

For a PMP® candidate, the useful habit is to read a risk scenario for these features before looking for a strategy word: who owns the cause, whether the exposure exceeds the project's authority, what the response would cost, and how much time remains. In the 2026 PMP Examination Content Outline, planning and managing risk is a task within the Business Environment domain, and predictive, adaptive and hybrid approaches appear across all three domains, so the same reasoning can surface in quite different delivery contexts. Working through realistic scenarios where ownership, timing and proportionality point towards different responses is central to how we approach risk in Omega's PMP® Exam Preparation, because that reasoning transfers directly back to live projects.

On a real project, a simple test keeps a register honest. For each planned response, can someone name the cause or consequence it acts on, the person who owns it, what it costs relative to the exposure, and the date by which it must happen? A row that cannot answer those four points holds a label rather than a response, and it is worth revisiting before the window it depends on quietly closes.

Andre Malowney

Interested in going further?

Choosing a risk response means weighing ownership, timing and proportionality under incomplete information, often while a tidier-looking answer sits in the register. Structured PMP® preparation gives you room to rehearse that reasoning on realistic scenarios before a live project asks for it.

The PMBOK® Guide Eighth Edition sets Plan Risk Responses in the context of the wider Risk Performance Domain and is the natural reference for this topic.

Ad · Amazon affiliate link.

References

A152: The PMBOK 8 Risk Performance Domain: What It Really Covers
A153: Risk vs Issue: The Difference That Changes What You Do Next
A154: When Does a Risk Become an Issue?
A155: Risk Register vs Risk Report vs Issue Log: What Goes Where?
A157: Do Agile and Hybrid Projects Still Use Risk Registers?

PMP and PMBOK are registered marks of the Project Management Institute, Inc.