Skip to content

Risk Response Plan

At a glance

  • Purpose: Turn each significant risk into a named response with an owner, a trigger, and a cost — so that responding is a decision made in advance rather than a reaction under pressure.
  • Use it when: For every risk above the project's agreed threshold, after assessment. It is the second half of the risk register and the input to contingency planning.
  • Owner: The named risk owner for each response, not the project manager for all of them.
  • Related: Module 08 · Lab 17

How to use this template

  1. Write the response as a verb with an object — "prototype the record-matching with the records office's sample data" — not as an intention like "monitor closely".
  2. Name the strategy explicitly. The five are avoid, transfer, mitigate, accept, and escalate, and naming one forces the question "is this really the best we can do?".
  3. Define the trigger: the observable event that says the risk is happening. A risk with no trigger is discovered by surprise, and by then the response costs more.
  4. Put a cost and a date against the response. A response without a budget competes with everything else for unallocated time and will lose.
  5. Carry a contingency reserve for accepted risks, sized from their expected exposure, and state who may release it.

Field descriptions

Field What goes in it Watch out for
Risk ID The ID from the risk register Responses without an identified risk
Risk (short) Cause → effect, kept brief Restating the whole register row
Strategy Avoid / transfer / mitigate / accept / escalate "Mitigate" for everything
Response actions Concrete steps with owners and dates Verbs like "consider" or "ensure"
Trigger The observable signal that the risk is occurring A trigger nobody is watching for
Residual exposure Probability × impact after the response Assuming responses are fully effective
Response cost Money or time the response consumes Ignoring the cost of the response itself
Contingency Reserve held in case the risk occurs Contingency with no release authority
Fallback What happens if the response fails No plan B for the highest exposure

Blank template

# Risk Response Plan — [Project name]

| | |
| --- | --- |
| **Version** | [1.0] |
| **Threshold for planning a response** | [e.g. exposure of 6 or more on the 1–3 × 1–3 scale, or any risk to a legal obligation] |
| **Contingency reserve** | [Amount of money and time, and who authorises release] |

| Risk ID | Risk (short) | Strategy | Response actions | Owner | Trigger | Residual P × I | Response cost | Fallback |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| R-01 | [Cause → effect] | Mitigate | [Steps] | [Who] | [Observable signal] | [p × i] | [Cost] | [If the response fails] |

## Reserve sizing

| Risk ID | Exposure if it occurs | Probability | Expected cost | Included in reserve? |
| --- | --- | --- | --- | --- |
| R-01 | [Impact in money or days] | [p] | [p × impact] | Yes / No — accepted |

## Release authority

| Reserve band | Who may release it | Escalation if exceeded |
| --- | --- | --- |
| Up to [X] | [Project manager] | [Sponsor] |

## Review and closure

| Date | Risk ID | Status change | Reason |
| --- | --- | --- | --- |
| | R-01 | Closed / Occurred / Still open | [Evidence] |

Worked example

From Lab 17, on the admission portal — invented figures for teaching. Four risks, four different strategies:

Risk ID Risk Strategy Response Trigger Residual Cost
R-01 The eligibility rule set is not agreed with the admissions office before build starts → rework of the rules engine Avoid Sequence the rules engine after written sign-off; build only the submission path until then Sign-off not obtained by the design milestone 2 × 3 = 6 (was 3 × 5 = 15) 1 week of resequenced effort
R-02 Security review queue delays the integration → schedule slip on the critical path Transfer Contract the review to a certified external assessor with a 10-day service commitment Review request not acknowledged within 3 days 3 × 3 = 9 (was 3 × 5 = 15) External fee, agreed in advance
R-03 Applicant data retention period is not confirmed → compliance exposure Mitigate Implement retention as configuration; obtain the confirmation in parallel Records office declines to confirm by the data-model milestone 2 × 5 = 10 3 days of configuration work
R-04 Peak load during the admission window exceeds current capacity Accept No change to the design; monitor and scale operationally Sustained response times above the agreed threshold 3 × 3 = 9 Reserve held, not spent

Two lessons are worth pulling out. First, R-02 is the only risk where the response costs money and is still correct, because the exposure sits on the critical path — see Lab 10 for why external queue time is critical here. Second, R-04's honest answer is "accept": the response is monitoring plus a reserve, and pretending otherwise would consume effort for no reduction in exposure. Lab 17's exercise is precisely to argue which risks deserve which strategy, and to show that accept is a strategy, not an omission.

Common mistakes

  • "Monitor closely" as a response. It is not a response; it is a decision not to respond, which may be fine — but say accept and hold a reserve.
  • Mitigation for everything. It conceals opportunities to avoid the risk entirely or transfer it.
  • No trigger. Without an observable signal, the response begins only after the impact is felt.
  • Ignoring the response's own cost and new risks. Reducing a schedule risk by fast-tracking introduces a rework risk, which belongs in the register.
  • Contingency that is really a buffer already spent. If the reserve is inside the baseline, it cannot absorb anything.
  • Assigning every risk to the project manager. Risk owners should be the people who can actually act.
  • No fallback for the largest exposure. For high-impact risks, the fallback is the plan that matters when the mitigation fails.