Mitigation and contingency are two different types of risk response. A mitigating action is what you do before a risk happens to reduce its likelihood or impact. A contingent action is what you do if the risk actually happens.

This is one of the most common points of confusion in project risk registers. People write “monitor the risk” in the mitigation column, put the same action in both columns, or leave contingency blank because nobody wants to think about what happens when the risk becomes real.

That is how risk registers become decorative. They look like project governance, but when something goes wrong, nobody knows what they agreed to do next.

Mitigation vs contingency: quick answer

The simplest way to remember the difference is:

• Mitigation is action taken before a risk happens.
• Contingency is action taken after a risk happens.

For example, if the risk is that a supplier may deliver late:

• Mitigation: confirm supplier milestones weekly and track delivery progress.
• Contingency: use an alternative supplier and resequence testing if delivery slips.

Mitigation tries to stop the risk happening, or reduce the damage if it does. Contingency accepts that the risk might still happen and sets out the backup plan.

What is mitigation in project risk management?

Mitigation is action taken to reduce the likelihood or impact of a risk before it becomes an issue.

Good mitigation is proactive. It should make the risk less likely to happen, less damaging if it happens, or easier to manage if warning signs appear.

Examples of mitigation include:

• adding a formal change control process to reduce scope creep;
• checking supplier progress before key delivery dates;
• adding quality reviews before final approval;
• cross-training another team member to reduce reliance on one expert;
• building schedule contingency into a project plan;
• clarifying decision rights before governance delays occur;
• agreeing communication rules before stakeholders complain they were not consulted.

Mitigation is not just a note saying “watch this”. Monitoring may help you detect a risk, but it does not automatically reduce the risk.

Weak mitigation example

Monitor supplier delivery.

This is weak because it does not say what will be done to reduce the risk. It also does not explain who is doing it, how often, or what action will be taken if warning signs appear.

Better mitigation example

Procurement lead to confirm supplier milestones every Friday, record progress against the delivery schedule, and escalate any missed milestone within one working day.

That is much better. It is specific, owned and action-focused.

What is contingency in project risk management?

Contingency is the fallback action you will take if the risk happens.

A contingency plan does not prevent the risk. It answers the question: what will we do if this risk becomes real?

Examples of contingency include:

• using an alternative supplier if the primary supplier misses the agreed delivery date;
• reordering project activities if testing is delayed;
• using a manual process if a system is not ready on time;
• requesting approval to use contingency budget;
• escalating a decision to the sponsor if governance approval is missed;
• reducing scope if the project cannot meet the deadline with the full set of requirements;
• moving a go-live date if minimum launch criteria are not met.

Contingency is not pessimism. It is sensible planning. Projects rarely fail because someone thought carefully about backup options. They fail because everyone pretended the risk was “being monitored” until the deadline was already on fire.

Mitigation vs contingency comparison table

The two terms are closely related, but they are not interchangeable.

Question	Mitigation	Contingency
When does it happen?	Before the risk happens.	After the risk happens, or when a trigger point is reached.
What is the purpose?	Reduce likelihood or impact.	Limit damage and recover if the risk occurs.
Typical wording	Confirm, review, test, validate, train, agree, schedule, reduce.	Escalate, switch, activate, use backup, resequence, recover, defer.
Example	Confirm supplier milestones weekly.	Use alternative supplier if delivery slips.
Where it appears in a risk register	Mitigating Action column.	Contingent Action column.

Supplier delay example

Supplier delay is a useful example because it makes the difference between mitigation and contingency obvious.

Risk description	If the supplier misses the delivery date, testing will be delayed and the project may miss the planned launch date.
Likelihood	Medium
Impact	High
Severity	High
Mitigating action	Confirm supplier milestones weekly, request written progress updates, and escalate any missed milestone within one working day.
Contingent action	If delivery slips by more than five working days, use an approved alternative supplier and resequence testing to protect the launch date.

The mitigation tries to stop the delay from happening or catch it early. The contingency describes what the project will do if the delay actually occurs.

Examples for a project risk register

Here are practical examples you can use as a starting point in a project risk register.

Scope creep

Risk	If uncontrolled changes are added to the project, the delivery date and budget may be affected.
Mitigation	Agree a change control process and require all new requirements to be assessed for cost, time and benefit impact.
Contingency	If significant scope change is approved, rebaseline the project plan and seek sponsor approval for revised cost or timeline.

Key person unavailable

Risk	If the only technical expert becomes unavailable, key design decisions may be delayed.
Mitigation	Document key technical decisions and pair the expert with a backup team member for knowledge transfer.
Contingency	If the expert becomes unavailable, use the backup technical reviewer and escalate unresolved decisions to the technical governance group.

Poor stakeholder communication

Risk	If stakeholders are not kept informed, they may resist decisions or raise objections late in the project.
Mitigation	Create a communication plan, agree key stakeholder groups, and send regular updates at agreed points in the project.
Contingency	If resistance escalates, hold targeted stakeholder sessions and escalate unresolved concerns to the sponsor for decision.

Testing takes longer than expected

Risk	If testing takes longer than planned, defect fixes may delay the implementation date.
Mitigation	Define test entry criteria, prepare test scripts early, and review defect trends during testing.
Contingency	If testing overruns, prioritise critical defects, defer non-critical changes, and agree revised go-live criteria.

Common mistakes with mitigation and contingency

Writing the same action in both columns

If the mitigating action and contingent action are identical, one of them is probably wrong. They serve different purposes. Mitigation is prevention or reduction. Contingency is response and recovery.

Using “monitor” as the whole mitigation plan

Monitoring is not enough. It tells you that something may be going wrong. It does not, by itself, reduce likelihood or impact.

If you write “monitor progress”, add what happens next:

• who monitors it;
• how often it is reviewed;
• what trigger causes escalation;
• what action will be taken if progress slips.

Leaving contingency blank

A blank contingency column is a warning sign. It usually means the team has identified a risk but has not agreed what to do if it happens.

For low risks, that may be acceptable. For High risks, it is not.

Writing vague actions

Vague actions are nearly useless in a risk register.

Weak wording	Better wording
Discuss with supplier.	Procurement lead to agree revised supplier milestones by Friday and confirm them in writing.
Improve communication.	Project manager to issue fortnightly stakeholder update and hold monthly decision review with sponsor.
Use contingency.	If testing slips by more than five working days, defer non-critical defects and request approval to use schedule contingency.

Not assigning an owner

Actions need owners. A mitigation action without an owner is a polite hope. A contingency action without an owner is a future argument waiting to happen.

How to enter mitigation and contingency in an Excel risk register

In an Excel risk register, the mitigating action and contingent action columns should be practical and specific. The person reading the register should be able to understand what action is planned without needing a separate meeting to decode it.

For each risk, try to include:

• the action - what will be done;
• the owner - who will do it;
• the trigger - when contingency starts;
• the outcome - what the action is meant to protect.

A useful format is:

[Owner] will [action] by [date/frequency] to [reduce likelihood, reduce impact or respond if triggered].

For example:

Procurement lead will review supplier milestones every Friday and escalate any missed milestone within one working day.

For spreadsheet support, see how to add a new risk to an Excel risk register.

When to update mitigation and contingency actions

Update mitigation and contingency actions when the risk changes, an action is completed, a trigger point is reached, or the project plan changes.

Mitigation and contingency actions should change when the risk changes.

Update them when:

• likelihood increases or decreases;
• impact changes;
• a mitigation action has been completed;
• the risk owner changes;
• a trigger point is reached;
• the risk becomes an issue;
• the project plan, supplier plan or delivery date changes.

Do not leave old actions in the register just because they were once true. A risk register is a live project document. If the actions are stale, the register is stale.

What should happen when contingency is triggered?

A contingency action should not be vague. It should have a trigger.

Examples of useful triggers include:

• supplier milestone missed by more than five working days;
• defect count above agreed tolerance;
• decision not made by the project board date;
• key resource unavailable for more than two weeks;
• cost forecast exceeds approved tolerance;
• test exit criteria not met by the planned date.

Once the trigger is reached, the contingency action should be activated, escalated or reviewed. Otherwise, it is not really a contingency plan. It is just text in a spreadsheet.

Mitigation, contingency and risk status

Mitigation and contingency actions should also influence the risk status.

• Open - the risk is active and actions still need to be managed.
• In progress - mitigation is underway or contingency planning is being developed.
• Closed - the risk no longer needs active management.

If a High risk has no mitigation, no contingency and no owner, it should not quietly remain “Open” for months. It needs attention.

For more detail, see how to use risk status properly.

Download the Excel risk register template

Use the free Excel risk register template to record project risks, select likelihood and impact, assess severity, assign owners and track mitigation and contingency actions.

Download the Excel risk register template

Related guides

• How to use a project risk register in Excel
• Likelihood, impact and severity in a risk register
• How to score project risks using a risk matrix
• How to write a good project risk description
• Risk owner vs action owner

Mitigation vs contingency FAQs

What is the difference between mitigation and contingency?

Mitigation is action taken before a risk happens to reduce likelihood or impact. Contingency is action taken if the risk happens.

Is monitoring a risk the same as mitigation?

No. Monitoring helps you detect changes, but it does not automatically reduce the risk. Monitoring can support mitigation, but it should not be the whole mitigation plan.

Can a risk have both mitigation and contingency?

Yes. Important risks should usually have both. Mitigation reduces the chance or impact of the risk. Contingency explains what will happen if the risk still occurs.

Should every risk have a contingency plan?

Not always. Low risks may not need a detailed contingency plan. High risks usually should. If a risk could seriously affect time, cost, quality, benefits or safety, it needs a clear response.

Who owns mitigation and contingency actions?

The risk owner is accountable for ensuring the actions are managed, but individual actions may be assigned to action owners. For example, the procurement lead may own supplier mitigation while the project manager owns schedule resequencing.

When does a contingency plan become an issue plan?

When the risk has happened, it is no longer just a risk. It becomes an issue. The contingency action may become part of the issue response plan.

What is an example of mitigation?

For a supplier delay risk, mitigation could be: “Procurement lead to confirm supplier milestones weekly and escalate any missed milestone within one working day.”

What is an example of contingency?

For a supplier delay risk, contingency could be: “If delivery slips by more than five working days, use an alternative supplier and resequence testing.”

Summary

Mitigation and contingency are both risk responses, but they are not the same thing. Mitigation is proactive. It tries to reduce the chance or effect of a risk before it happens. Contingency is responsive. It sets out what the project will do if the risk becomes real.

A useful risk register needs both. Without mitigation, the team may not be doing enough to reduce the risk. Without contingency, the team may have no agreed plan when the risk turns into an issue.