Risk Response Planning

From Register to Response

The risk register after analysis has a specific character. Risk 2 sits at the top, scored 16 out of 25, marked "awaiting strategy implementation" with a named owner and an open status. That entry is not a completed task. It is the beginning of the real work. Knowing a risk is high priority tells you where to direct attention. It does not tell you what to do. Risk response planning answers the second question: for each risk that warrants action, what specifically will the team do, who will do it, and by when? A register without response plans is a documented list of concerns. A register with response plans is a management instrument.

How to Choose a Response Strategy

The response strategies for threats are not a fixed ranking, but they are not interchangeable either. Start with the right question: is this risk within the project team's authority? If not, escalate. If it is, choose the response that fits severity, cost, feasibility, timing, and risk appetite. Avoid when you can remove the cause. Transfer when a market exists to absorb the financial exposure. Mitigate when targeted action can reduce probability, impact, or both. Accept when the cost and effort of any proactive response exceed what the risk is worth, but accept deliberately, with documented reasoning. Accepting a low-impact risk after analysis is sound risk management. Accepting a high-impact risk to avoid the work of planning is not. "We accepted this risk because mitigation costs exceed the expected value" is a defensible choice. "We accepted this risk because we did not want to discuss it" is not.

Escalate — When the Risk Is Above Your Authority

Some risks exceed the project manager's authority to respond. A threat with a potential cost impact that exceeds the management reserve threshold, or one whose response would require a scope change that only the sponsor can authorize, cannot be managed at the project level. The appropriate response is escalation: document the risk clearly, pass it to the appropriate level of authority, and formally transfer ownership. The project manager does not accept a high-impact risk on the sponsor's behalf. That decision belongs to whoever has the authority to commit the resources or absorb the consequence. The same logic applies to opportunities: if realizing an upside requires investment or scope change beyond the PM's approval threshold, it goes up rather than being quietly abandoned. After escalation, ownership moves to the appropriate authority. The project register should retain a linked entry showing escalation status, the decision-owner, the date, and any project-level impacts still being monitored. Escalating a risk does not end the project team's need for visibility.

Avoid — Eliminate the Risk by Changing the Plan

Avoidance means changing the project approach so the risk cannot occur. It is the cleanest response when feasible and proportionate because it removes the specific threat entirely. A critical deliverable that depends on a vendor with a history of late delivery can be rerouted: use an internal team, a pre-qualified backup supplier, or a different delivery model that eliminates the dependency. Avoidance is never free. The alternative approach usually costs more, takes longer, or requires more internal resource than the original plan. The decision requires a judgment that the cost of avoidance is less than the expected cost of the risk itself. If the alternative approach costs $15,000 more and the risk's expected monetary value is $40,000, the math supports avoidance. If the alternative costs $50,000 and the EMV is $8,000, it does not. Avoidance is appropriate when the risk's potential impact is severe enough that no mitigation can reduce it to an acceptable level.

Transfer — Shift the Financial Consequence

Transfer means moving the financial burden of a risk to a third party. Insurance is the most familiar form: the project pays a premium, and the insurer absorbs the loss if the risk materializes. A fixed-price contract with a vendor transfers delivery cost risk: if the vendor cannot meet the agreed price, they absorb the overrun, not the project. A contractual indemnification clause shifts specific categories of liability to the contracting party. Transfer does not eliminate the risk event. The event can still occur. What it eliminates is who bears the financial consequence if it does. A project that transfers delivery risk through a fixed-price contract is still exposed to schedule impact if the vendor fails to deliver on time. Reputational, schedule, and operational risks do not transfer with the financial risk unless the contract is written explicitly to cover them. Transfer moves financial liability but not accountability for delivering the project outcome. That remains with the project. Transfer is appropriate when a market exists to absorb the financial exposure at a cost less than the expected loss, and when the non-financial residual risk is acceptable.

Mitigate — Reduce Probability, Impact, or Both

Mitigation is the most commonly applied response strategy because most risks can be improved through targeted action even when they cannot be avoided or practically transferred. The key insight most teams miss: mitigation applies to probability and impact as two independent levers, not one combined target. A risk can be mitigated on the probability side by taking actions to make it less likely to occur, while leaving the impact side unchanged. It can be mitigated on the impact side by reducing the damage if it does occur, while the probability remains the same. Both levers can be pulled simultaneously. For the RtR service continuity risk, one mitigation reduced probability: establishing an offsite emergency operations capability before the move window reduced the likelihood of a service gap. A separate mitigation reduced impact: a pre-agreed client communication protocol set expectations for any brief interruption and preserved the relationship even if one occurred. Effective mitigation always revisits the scores after the actions are implemented. If probability, impact, urgency, or response readiness did not improve, the mitigation probably did not work.

Accept — When the Response Costs More Than the Risk

Acceptance is a legitimate strategy when the cost and effort of a proactive response exceed the expected value of the risk, or when no effective proactive response exists. It is not negligence. It is a deliberate judgment made against the numbers. Active acceptance means developing a contingency plan: a defined response that will be implemented if the risk materializes, funded from the contingency reserve. The contingency plan is written before the risk occurs, activated by a pre-defined trigger condition, and owned by the named risk owner. Passive acceptance requires no contingency plan; the team acknowledges the risk and absorbs the impact if it occurs. Passive acceptance is appropriate only for risks whose potential impact is genuinely tolerable. Applying passive acceptance to a high-impact risk is the most common way risk management fails: it looks correct on paper while providing none of the protection the process was supposed to deliver.

Is the Response Worth It?

Every response strategy has a cost: staff time, vendor fees, insurance premiums, schedule extensions, or design changes. Before committing to a response, that cost should be compared against the expected monetary value of the risk. The comparison is straightforward: if a mitigation costs $5,000 in project resources and the risk's EMV is $3,000, the mitigation is not economically justified unless a non-financial factor changes the calculation. Reputational exposure, regulatory requirements, contractual obligations, or a risk whose non-quantifiable tail is too severe to ignore are all legitimate reasons to proceed anyway. If the mitigation costs $5,000 and the EMV is $20,000, it is clearly worth pursuing. The expected value framework does not make every decision obvious, but it provides a defensible basis for the ones that are not.

Opportunity Response Strategies

Opportunities are managed through a parallel set of strategies following the same sequencing logic: start from the strongest practical response and document the reasoning when a weaker one is chosen instead.

Escalate applies when capturing an opportunity requires investment or scope changes beyond the PM's authority. An opportunity that requires $80,000 in unbudgeted investment to exploit does not disappear because the PM cannot approve it. It gets escalated with a clear statement of the expected benefit and the investment required, then owned at whatever level can commit the resources.

Exploit means eliminating the uncertainty on the positive side by taking action to ensure the opportunity occurs. Just as Avoid removes the possibility of a threat materializing, Exploit removes the chance that a beneficial event fails to happen. This is the most resource-intensive opportunity response and is appropriate when the expected benefit justifies the cost of guaranteeing the outcome.

Enhance means increasing either the probability or the value of an opportunity, the positive counterpart of Mitigate. Targeted actions make a beneficial outcome more likely or more valuable without guaranteeing it. For the RtR project, the engineering firm opportunity was enhanced by bringing the partner into the location assessment earlier and using their build-to-suit analysis during negotiations, improving the odds of better property terms without committing the result.

Sharing the opportunity means identifying a party better positioned to realize it and structuring an arrangement so the project benefits from what they capture. Instead of the project team pursuing an upside it lacks the capability or authority to reach, the opportunity goes to whoever is best equipped to act on it. Both parties benefit from the arrangement.

For low-probability upsides where the cost of proactive pursuit is not justified by the potential benefit, Accept is the right call. If the opportunity materializes on its own, the team takes advantage. If it does not, no resources were spent on the attempt. This is the same judgment as passive threat acceptance: a deliberate decision, not an oversight.

Contingency Plans, Fallback Plans, and Workarounds

Three distinct tools handle the space between a risk being identified and a risk being resolved, and conflating them creates gaps that show up during execution.

A contingency plan is a pre-written response to a specific risk, triggered by a defined condition. It is most common for accepted risks, but it also supports mitigated, transferred, or partially avoided risks where residual exposure remains and a defined response is needed if that exposure materializes. The contingency plan exists before it is needed. When the trigger fires, the response is implemented from a document that was already written, not invented under pressure.

A fallback plan is a backup for when the primary response fails. If the mitigation strategy does not hold, or if the contingency plan is activated and proves insufficient, the fallback defines what comes next. Projects that plan only to the first response level leave themselves without a defined path when that response does not hold.

The third situation is a workaround: an improvised response used when no prepared response exists, or when the prepared response fails under actual conditions. Workarounds are sometimes the only available option. But they are far more expensive in time and money than a contingency plan written before the event, and they are a signal that either identification missed something or the monitoring cadence was too slow to catch the trigger in time.

Residual Risk and Secondary Risks

Every response creates a new picture of the risk landscape that must be documented. Residual risk is what remains after a response is applied. It has its own score, its own owner, and its own monitoring schedule. A threat scored 16 that is mitigated to a score of 6 is still a score-6 threat on the register, requiring whatever monitoring and contingency the score-6 tier demands. Treating a mitigated risk as a closed item is one of the most consistent failure modes in risk execution: the register shows a response strategy, and no one checks what the risk looks like after the strategy runs.

The response itself can also introduce new uncertainty. A decision to avoid a vendor risk by bringing work in-house creates a resource risk: the internal team is now carrying work it was not originally scheduled to absorb. A decision to fast-track the schedule to avoid a cost penalty creates a quality risk: parallel activities that were kept separate to allow review time are now running simultaneously. Secondary risks get their own register entries, their own owners, and their own response strategies. They are a routine product of response planning, not an exception to it.

Risk Owners — Who Is Accountable

A risk without a named owner is a risk no one is managing. The risk owner is accountable for executing the agreed response, monitoring whether the probability or impact has changed, escalating when the risk approaches its threshold, and reporting status at agreed review intervals. Risk owners are typically not the project manager. They are usually the person closest to the risk's source: the technical lead owns the technical risk, the procurement coordinator owns the vendor risk, the facilities manager owns the site preparation risk. Assigning ownership to the most knowledgeable person produces faster escalation and more accurate monitoring than routing all oversight through the PM.

The project manager is accountable for the risk management process, not automatically for every individual risk. The PM may still own some risks directly, particularly integration or governance risks where no single team member is closer to the source. But most risks belong with the person who can see and act on them fastest. The PM's job is to confirm that risk owners are fulfilling their responsibilities, that the register is reviewed on schedule, and that risks are not quietly downgraded when they should be escalated. A register full of named owners who never update their entries, and a PM who never follows up, is not a functioning risk management system. It is a document.

Closing a Risk

A risk can be closed when one of three conditions is met: the trigger window has passed and the risk can no longer materialize; the response has been fully implemented and the residual level is acceptable with no further monitoring required; or the project has moved past the stage that would have exposed it. If residual exposure still needs active review, keep the entry open in monitoring status rather than marking it closed. Closing a risk is not the same as ignoring it. When a risk closes, the register should document why it closed, what response was applied, what the outcome was, and whether the response worked as intended. R-03 in the RtR register closed not because the team took preventive action but because the regulatory announcement that drove the risk was withdrawn before the project reached design lock. That closure is documented with a reason. If a future project encounters a similar regulatory risk, the entry for R-03 becomes a useful data point: the team will know that this specific regulation was monitored for four months and ultimately did not affect the project. That is the lessons learned function of the register, and it only works if closures are recorded with context rather than quietly deleted.

RtR Risk Responses — The Register in Action

The table below shows the three documented RtR risks with their analysis scores and selected response strategies. R-02 drove the most planning effort. R-01 was enhanced by engaging the engineering partner earlier in location assessment. R-03 combined a light mitigation (modular design) with active acceptance, monitored on a defined cadence, and closed when the regulatory environment resolved.

ID	Summary	Score	Strategy	Response Action	Residual Status
R-01	Engineering firm relationship enables build-to-suit negotiations (Opportunity)	9	Enhance	Engage engineering partner in early location assessment; use build-to-suit feasibility data to strengthen negotiation position before location selection closes	Opportunity being pursued through earlier vendor engagement. Probability of improved property terms: moderate.
R-02	24/7 emergency services continuity at risk during relocation window (Threat)	16	Avoid	Establish operational offsite emergency services centre before move window begins; no physical move starts until offsite continuity is confirmed	Residual: temporary site operating cost and schedule dependency on offsite setup. Monitoring continues through transition.
R-03	Workplace health, safety, or occupancy regulations may require design rework (Threat)	6	Mitigate + Accept	Design held modular to reduce rework impact if regulations materialize; assumption validated at 4-week intervals	Closed — regulations withdrawn before design lock. Documented with reason.

R-02's response required the most planning effort. It is classified as Avoid, not Mitigate, because the physical move cannot begin until the offsite centre is operational. That sequencing removes the service continuity risk entirely rather than reducing it. Adding redundancy while the main office moves would be mitigation; refusing to move until continuity is confirmed is avoidance. R-01 was enhanced rather than exploited because the outcome depended on landlord negotiations the PM could not fully control — the engineering partner was engaged earlier and more deeply, but guaranteeing a favorable deal was not within the project's authority. R-03 combined a low-cost mitigation (modular design reduces rework impact) with active acceptance monitored every four weeks, and was closed with a documented reason when the regulatory announcement was withdrawn.

The RtR Risk Register — Identification Through Response

The table below shows the three documented RtR risks as a single complete register, spanning all three stages of risk management: identification (category, type, description), analysis (impact, probability, score), and response planning (strategy, action, owner, status). This is what a working register looks like when the full process has run.

What's Next

Risk response planning closes out the risk management section of the project plan. Planning moves next to the people and materials side of the project: Resource Planning covers how the project identifies what human and physical resources it needs, matches them to the work, and manages their availability across the project timeline.

Reflect

• On the last project you were involved with, what response strategy did the team default to most often? If it was Accept, was that a deliberate judgment against the numbers, or was it the path of least resistance?
• Think of a risk response you have seen implemented. Did the response also create secondary risks? Were those secondary risks documented and managed, or did they surface later as surprises during execution?
• What is the difference between a contingency plan and a workaround in your team's current practice? Does your team have written contingency plans for your highest-scored risks, or are most responses being improvised after the trigger fires?
• Who owns the individual risks on your current or most recent project? If the answer is the project manager for everything, what would it take to transfer each risk to the person closest to its source?
• Think of a risk that was closed on a project you know. Was the closure documented with a reason, and did that documentation make it into lessons learned for future reference?