Identifying and assessing a risk is not enough. Once a risk has been understood and prioritised, the organisation must decide what it will do about it.
A risk response strategy—also called a risk treatment strategy—is the overall approach chosen to address an identified risk. For threats, the four principal strategies are:
- Avoid the risk.
- Mitigate the probability or impact.
- Transfer some or all of the consequences to another party.
- Accept the risk and prepare for its possible occurrence.
Choosing the strategy is only the beginning. An effective response must also be appropriate to the risk, practical to execute, agreed by the relevant stakeholders, assigned to an owner, and incorporated into ordinary project or operational work.
This guide explains the four strategies, how to choose between them, and how to turn a decision into an executable treatment plan.
What is a risk response?
A risk response is a planned course of action for dealing with uncertainty. It should answer two questions:
- What approach will we take toward this risk?
- What specific actions will we perform?
These are related but distinct.
For example:
- Strategy: Mitigate the risk.
- Treatment action: Run an early proof of concept, engage an experienced consultant, and complete integration testing before development begins.
The strategy establishes the direction. The treatment actions turn that direction into work.
The four main risk response strategies
1. Avoid the risk
Risk avoidance aims to eliminate the threat by removing its cause or declining to undertake the activity that creates it.
Avoidance is the strongest response because, when successful, the risk no longer exists. It may involve:
- changing the project scope;
- abandoning a risky feature or activity;
- replacing an unreliable technology or supplier;
- altering the delivery approach;
- removing a hazardous dependency; or
- selecting an alternative that does not create the same exposure.
Example
A project includes a technically complex enhancement that is poorly understood and likely to delay a fixed launch date. The organisation decides to remove the enhancement from the initial release.
By changing the scope, the project avoids the schedule risk associated with that enhancement.
Another example
A project depends on a shared specialist who is frequently reassigned at short notice. Rather than continuing with the shared-resource model, the project secures a dedicated specialist whose availability it controls.
Avoidance is appropriate when the exposure is unacceptable and the underlying activity is not essential. It may be unsuitable when avoiding the risk would also eliminate an important benefit or make the project unviable.
2. Mitigate the risk
Risk mitigation aims to reduce either:
- the probability that the risk will occur;
- the impact if it does occur; or
- both probability and impact.
Mitigation is often the most common response because many risks cannot be eliminated completely. Typical mitigation actions include:
- prototyping or testing early;
- introducing quality controls;
- adding schedule or budget contingency;
- providing training;
- increasing redundancy;
- simplifying a design;
- improving monitoring;
- using staged delivery;
- strengthening security controls; or
- obtaining specialist advice.
Example
A development team must use an unfamiliar technology, creating a risk that technical difficulties will delay delivery. The project engages an experienced consultant to coach the team, review the architecture, and resolve difficult issues.
This treatment reduces the probability that technical problems will cause a significant delay.
Another example
A project depends on a single supplier. The team qualifies a secondary supplier and keeps a small reserve of critical components.
These actions may not eliminate supplier failure, but they reduce its potential impact.
A mitigation plan should state precisely how the proposed actions will change the exposure. “Monitor the risk” is not usually a mitigation strategy by itself; monitoring provides information, but it does not necessarily reduce probability or impact.
3. Transfer the risk
Risk transfer moves responsibility for some of the financial or operational consequences to another party.
Common transfer mechanisms include:
- insurance;
- warranties;
- indemnities;
- fixed-price contracts;
- performance guarantees;
- outsourcing;
- service-level agreements; and
- contractual liability provisions.
Example
An organisation purchases property insurance to reduce the financial consequences of fire damage. The physical event could still occur, but much of the financial loss is transferred to the insurer.
Another example
A project uses a fixed-price contract for a clearly specified package of work. Some cost-overrun exposure is transferred to the supplier, subject to the terms of the contract.
Transfer does not normally make the underlying risk disappear. It changes who bears particular consequences. The organisation may retain significant exposure, including:
- reputational damage;
- schedule delays;
- service interruption;
- legal obligations;
- supplier failure; or
- costs outside the contract or policy.
A transfer strategy should therefore be reviewed carefully with procurement, legal, insurance, or commercial specialists where appropriate.
4. Accept the risk
Risk acceptance means acknowledging the exposure and deciding not to take further preventive action beyond normal monitoring and contingency planning.
Acceptance can be:
- passive, where the organisation records the risk and takes no additional action; or
- active, where it establishes contingency reserves, fallback plans, trigger conditions, or recovery actions.
Acceptance may be appropriate when:
- no practical alternative exists;
- the exposure is within tolerance;
- treatment would cost more than the expected benefit;
- the risk is low priority;
- action would create greater secondary risks; or
- the organisation consciously chooses to pursue the associated opportunity.
Example
A project depends on government approval, but the approval process cannot be accelerated or transferred. The project accepts the schedule risk while monitoring the application and preparing a contingency plan.
Another example
A shared cloud resource could occasionally delay processing by several days. A dedicated environment would eliminate much of the exposure, but its cost is disproportionate to the likely impact. The organisation accepts the risk.
Acceptance should be an explicit decision, not the accidental result of inaction. The rationale, approving authority, review date, and any contingency arrangements should be recorded.
How to choose the right response
The most suitable strategy depends on the nature and level of the risk, the organisation’s objectives, and its available resources.
Consider the following questions:
-
Can the source of the risk be removed?
If so, avoidance may be possible. -
Can probability or impact be reduced at a reasonable cost?
If so, mitigation may be suitable. -
Can another party manage particular consequences more effectively?
If so, consider transfer. -
Is the remaining exposure within tolerance?
If so, acceptance may be appropriate. -
Will the response introduce new risks?
Every treatment can create secondary risks that also need assessment. -
Will the treatment cost more than the likely benefit?
The response should be proportionate to the exposure.
More than one strategy may be used for the same risk. An organisation might mitigate a cyber risk through controls, transfer part of the financial exposure through insurance, and accept the remaining residual risk.
The AAA test for a strong risk response
A sound strategic choice can still fail if the response is vague, impractical, or unsupported. A useful quality test is to ensure that the response is appropriate, actionable, and agreed.
Appropriate
The response should be proportionate to the risk and consistent with the organisation’s risk tolerance.
A treatment expected to cost more than the consequences it is intended to prevent may not be justified. Cost is not the only consideration—safety, legal duties, reputation, and strategic importance may outweigh a simple financial calculation—but the response should still make sense in context.
An appropriate response should:
- address the actual causes or consequences of the risk;
- fit the assessed level of exposure;
- support project and organisational objectives;
- account for relevant obligations; and
- remain affordable within the available budget.
Actionable
The response must be feasible. It should lie within the organisation’s technical capability, authority, time, and resources.
“Invent a completely new database platform” is not a practical treatment for most teams facing a performance concern with an off-the-shelf product.
An actionable response should specify:
- concrete activities;
- a responsible owner;
- required resources;
- an achievable timeframe;
- dependencies;
- decision or trigger points; and
- a measurable completion or success criterion.
Agreed
The response should be approved by the people who must fund, authorise, perform, or depend upon it.
Agreement is especially important where the treatment:
- changes scope or schedule;
- requires contingency funding;
- imposes work on another team;
- transfers contractual exposure;
- affects customers or suppliers; or
- requires acceptance of residual risk.
Each response should have one clearly accountable owner, even when several people perform the work.
Turning a response strategy into a treatment plan
A risk response becomes useful only when it is converted into executable work.
A practical treatment plan should include:
| Field | What to record |
|---|---|
| Strategy | Avoid, mitigate, transfer, or accept |
| Treatment actions | The specific work that will be performed |
| Response owner | The person accountable for the response |
| Action owners | The people responsible for individual tasks |
| Due dates | When each action must be completed |
| Resources and budget | What is required to perform the work |
| Trigger conditions | Events or thresholds that activate contingency actions |
| Expected effect | How the action should change probability or impact |
| Residual risk | The exposure expected after treatment |
| Status | Planned, in progress, complete, ineffective, or cancelled |
| Review date | When effectiveness will be reassessed |
Assign an accountable owner
Every response should have a person responsible for ensuring that it is executed. Without clear ownership, treatment plans tend to remain as notes in a risk register.
The risk owner and response owner may be the same person, but they do not have to be. The important point is that accountability is explicit.
Allocate realistic resources
A treatment without sufficient time, money, authority, or specialist support is not a plan.
Estimate the required:
- effort;
- duration;
- budget;
- personnel;
- procurement;
- approvals; and
- technical resources.
Where funding is required, include it in the project budget or contingency and obtain approval before it is needed.
Put treatment actions into the delivery plan
Risk responses should not exist only inside the risk register. Convert them into scheduled activities and manage them alongside other project or operational work.
Each significant treatment action should have:
- a clear description;
- an owner;
- a due date;
- dependencies;
- status; and
- evidence of completion.
This is particularly important for mitigation actions that must be completed before a risk trigger or project milestone.
Monitor execution and effectiveness
Completing a treatment action does not prove that the risk has been reduced.
Monitor both:
- Implementation: Was the action completed as planned?
- Effectiveness: Did it actually reduce the probability or impact?
After treatment, reassess the risk and record its residual level. If the residual exposure remains unacceptable, additional action or a different strategy may be required.
Example: from identified risk to executed response
Risk statement
Because the project team has limited experience with the selected integration platform, there is a risk that technical problems will delay system testing and the production launch.
Initial assessment
- Probability: Likely
- Impact: Major
- Rating: High
Selected strategy
Mitigate.
Treatment plan
- Engage an integration specialist for architecture review.
- Build a proof of concept before full development.
- Complete performance and failure-mode testing early.
- Train two internal developers in platform support.
- Add a two-week contingency before production launch.
Owner
Technical delivery manager.
Expected effect
Reduce probability from Likely to Possible and impact from Major to Moderate.
Residual assessment
- Probability: Possible
- Impact: Moderate
- Rating: Medium
This example connects the strategic decision to specific actions, ownership, timing, and measurable risk reduction.
Tracking risk responses in Jira
Risk treatments are most effective when they are connected to the work required to deliver them.
With Risk Register by ProjectBalm, teams can manage risks in Jira, assess inherent and residual exposure, assign ownership, and link treatment activity to Jira work items. This allows treatment actions to be planned, assigned, monitored, and reported through the same system used for ordinary delivery work.
Learn more about risk management in Jira
Explore Risk Register features
Try Risk Register on the Atlassian Marketplace
Frequently asked questions
What are the four main risk response strategies?
The four main strategies for threats are avoid, mitigate, transfer, and accept. Avoidance removes the risk, mitigation reduces probability or impact, transfer shifts particular consequences to another party, and acceptance acknowledges the remaining exposure.
What is the difference between a risk response and a risk treatment?
The terms are often used interchangeably. “Response strategy” commonly describes the overall approach—such as mitigate or accept—while “treatment” can refer to the specific actions used to implement that approach.
Can a risk have more than one response strategy?
Yes. A team may mitigate a risk through preventive controls, transfer part of the financial consequence through insurance, and accept the remaining residual exposure.
Is monitoring a risk response strategy?
Monitoring is essential, but it does not normally reduce a risk by itself. It supports all four strategies by showing whether exposure has changed, whether triggers have occurred, and whether treatments are effective.
Who should own a risk response?
One person should be accountable for ensuring the response is implemented. Individual actions may be assigned to different people, but overall ownership should remain clear.
When should a risk be accepted?
Acceptance may be appropriate when the risk is within tolerance, no feasible treatment exists, or the cost and disruption of further action would be disproportionate to the expected benefit. The decision should be explicit and authorised.
References
- Hillson, D. (2003), Grade A Risk Responses, Risk Doctor Briefing Note #3. Available from Risk Doctor Briefings.
- Hillson, D. (2003), Get the Frogs off the Log, Risk Doctor Briefing Note #2. Available from Risk Doctor Briefings.