A project risk register is used to record potential risks, assess their likelihood and impact, assign owners, and track the actions being taken to manage them. This guide explains how to use a risk register in Excel without turning it into a dead spreadsheet nobody ever opens again.

A risk register is one of the simplest and most useful project management tools. It gives you one place to record what might go wrong, how serious each risk is, who is responsible for managing it, and what action is being taken.

The basic idea is straightforward: identify the risk before it becomes a problem, decide how serious it is, and agree what to do about it. The difficult bit is keeping the register clear, current and useful. A risk register should help people make decisions, not become a beautifully formatted graveyard of ignored worries.

What is a project risk register?

A project risk register is a document used to capture and manage risks throughout a project. It is normally created at the start of the project and updated as the project progresses.

A risk register usually includes:

• a unique risk ID;
• the date the risk was raised;
• a description of the risk;
• likelihood;
• impact;
• severity or risk rating;
• the risk owner;
• mitigating actions;
• contingency actions;
• progress notes;
• risk status.

In Excel, each risk is usually recorded on a separate row. The columns then help you assess, manage and monitor each risk.

What is the purpose of a risk register?

The purpose of a risk register is not just to list scary things. It is to support better project decisions.

A good risk register helps you:

• spot project risks early;
• agree which risks are most important;
• assign clear ownership;
• record what is being done to reduce the risk;
• prepare a backup plan if the risk happens;
• brief sponsors and stakeholders clearly;
• avoid pretending everything is fine until it obviously is not.

The last point is important. Many project risks do not arrive as a surprise. People often know they are coming, but the risk has not been written down, assigned, reviewed or escalated. A risk register makes that much harder to ignore.

How to use a risk register in Excel

To use a risk register in Excel, work through the spreadsheet row by row. Each row should describe one risk and the action being taken to manage it.

1. Add a risk ID

Give each risk a unique ID, such as R001, R002 or R003. This makes it easier to refer to risks in meetings, reports and project board papers.

For example, instead of saying, “that supplier delay risk we talked about last week,” you can say, “Risk R004 remains High because the supplier has not confirmed the delivery date.”

2. Record the date raised

The date raised shows when the risk was first added to the register. This helps you see how long a risk has been open and whether it is being actively managed.

If a high risk has been sitting in the register for three months with no progress, that tells you something. Either the risk is not being managed properly, or it was not really a high risk in the first place.

3. Write a clear risk description

The risk description should explain what might happen and why it matters. Avoid vague entries such as:

• Resources
• Communication
• Supplier
• Scope

Those are not useful risk descriptions. They are labels. A better risk description explains the possible event and the consequence.

For example:

If the supplier misses the delivery date, system testing will be delayed and the project may miss the planned launch date.

That is much more useful than simply writing supplier delay.

A good risk description often follows this pattern:

If [risk event happens], then [impact on the project], resulting in [consequence].

For a fuller explanation, see how to write a good project risk description.

4. Assess likelihood

Likelihood means how probable the risk is. In a simple risk register, this is often scored as:

• Low - unlikely to happen;
• Medium - possible;
• High - likely or already showing warning signs.

The aim is not to pretend you can predict the future with scientific precision. The aim is to have a sensible conversation about probability.

5. Assess impact

Impact means how serious the consequences would be if the risk happened. Impact can affect cost, time, quality, scope, benefits, safety, compliance, reputation or stakeholder confidence.

A risk may have a low likelihood but a very high impact. Those risks still deserve attention. For example, a major supplier collapse may be unlikely, but if it would stop the project completely, it should not be ignored.

For more detail, see likelihood, impact and severity explained.

6. Calculate severity

Severity is the overall risk rating. It is usually based on likelihood and impact. A simple Excel risk register may use a Low, Medium and High rating.

For example:

• Low likelihood and low impact = Low severity;
• Medium likelihood and medium impact = Medium severity;
• High likelihood and high impact = High severity.

A risk matrix helps you apply this consistently. See how to score project risks using a risk matrix.

7. Assign a risk owner

Every risk should have an owner. The risk owner is responsible for monitoring the risk and making sure the agreed actions happen.

Do not automatically assign every risk to the project manager. That makes the register look neat, but it can make it useless. The owner should be the person best placed to manage or influence the risk.

Examples:

• a technical design risk may belong to the technical lead;
• a benefits risk may belong to the business owner;
• a supplier performance risk may belong to the contract manager;
• a funding risk may belong to the sponsor.

For more detail, see risk owner vs action owner.

8. Add mitigating actions

A mitigating action is something you do now to reduce either the likelihood or the impact of the risk.

For example, if the risk is supplier delay, mitigation could include:

• confirming the supplier delivery date in writing;
• adding supplier milestones to the project plan;
• checking progress weekly;
• identifying alternative suppliers;
• ordering long-lead items earlier.

A weak mitigation is something like:

Monitor the risk.

Monitoring is not mitigation. It may be useful, but it does not reduce the chance or impact of the risk on its own.

9. Add contingent actions

A contingent action is the backup plan. It describes what you will do if the risk actually happens.

For example, if the supplier misses the delivery date, your contingent action might be:

• switch to an approved alternative supplier;
• resequence testing activities;
• use temporary manual processing;
• escalate to the supplier account manager;
• request approval to use contingency budget.

Mitigation and contingency are often confused. The simple difference is:

• mitigation is what you do before the risk happens;
• contingency is what you do if the risk happens.

See mitigating action vs contingent action for examples.

10. Update progress

The progress column should show what is actually happening. It should not be a dusty note that says “ongoing” for six months.

Useful progress notes include:

• what action has been completed;
• what remains outstanding;
• whether the risk rating has changed;
• whether the risk needs escalation;
• when the risk will next be reviewed.

If a risk is High, the progress note should explain why it is still High and what is happening next.

11. Set the status

A simple risk register may use statuses such as:

• Open - the risk is active and still needs monitoring;
• In progress - actions are underway;
• Closed - the risk no longer needs active management.

A risk can be closed when it is no longer relevant, the project has passed the point at which it could happen, or the risk has happened and is now being managed as an issue.

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

Example risk register row

Here is a simple example of how one risk might be recorded.

Field	Example entry
Risk ID	R004
Date raised	26/06/2026
Risk description	If the supplier misses the delivery date, system testing will be delayed and the project may miss the planned launch date.
Likelihood	Medium
Impact	High
Severity	High
Owner	Procurement lead
Mitigating action	Confirm delivery milestones with supplier and review progress weekly.
Contingent action	Escalate to supplier account manager and switch to approved alternative supplier if delivery slips by more than five working days.
Progress	Supplier has confirmed first delivery milestone. Next review due Friday.
Status	In progress

Common project risks to include

The risks you include will depend on the project, but common project risks include:

• unclear project objectives;
• scope creep;
• poor stakeholder communication;
• supplier or contractor delay;
• resources not being available when needed;
• over-optimistic estimates;
• technical problems discovered late;
• business requirements changing;
• lack of senior sponsor support;
• project benefits no longer being valid.

For examples, see common project risks and how to manage them.

How often should you review a risk register?

A risk register should be reviewed regularly throughout the project. For most active projects, a weekly review is sensible. For smaller or slower-moving projects, a fortnightly or monthly review may be enough.

You should also review the risk register:

• before project board or steering group meetings;
• before major milestones;
• after significant change requests;
• when a major issue occurs;
• when a supplier, budget or schedule assumption changes;
• when the project moves into a new phase.

The review should not be a box-ticking exercise. Ask:

• Are the High risks still High?
• Are any Medium risks becoming High?
• Are mitigation actions actually happening?
• Are the right people owning the risks?
• Does anything need to be escalated?
• Can any risks be closed?

See how often to review a project risk register.

Risk register mistakes to avoid

A risk register does not need to be complicated, but it does need to be useful. These are some of the most common mistakes.

Using vague risk descriptions

A risk called communication does not tell anyone what might happen or what to do. Write the risk as a possible event with a consequence.

Putting the project manager as the owner for every risk

The project manager may coordinate the register, but they should not automatically own every risk. Risk ownership should sit with the person who can manage, influence or escalate the risk effectively.

Confusing risks with issues

A risk is something that might happen. An issue is something that has already happened. If the supplier has already missed the delivery date, that is probably an issue, not a risk.

Writing weak mitigation actions

Actions such as “monitor”, “review” or “discuss” may be part of managing a risk, but they are often too weak on their own. A mitigation action should reduce likelihood or impact.

Never closing risks

A risk register should not keep every risk forever. Close risks that are no longer relevant, no longer possible, or have moved into issue management.

Letting the spreadsheet go stale

The best-looking risk register in the world is pointless if it is not updated. A risk register is a working project document, not a one-time admin task.

Excel tips for using the template

If you are using an Excel risk register template, take care when adding rows, editing dropdown lists or changing formulas. It is very easy to break a useful spreadsheet by pasting over validation, deleting formulas or changing the structure.

• Copy an existing row when adding a new risk so formulas and dropdowns are preserved.
• Do not type over calculated severity cells.
• Keep dropdown values consistent.
• Protect formula cells if other people will edit the workbook.
• Use filters to focus on High risks, open risks or risks owned by a particular person.
• Use conditional formatting to make High risks stand out.

Useful Excel guides:

• How to add a new risk to an Excel risk register
• How to edit dropdown lists in an Excel template
• How to protect formulas in an Excel template
• Excel dropdowns not working after copying rows?
• How to use conditional formatting in a risk register

Risk register guide links

This page is the main guide for using the Excel risk register template. The following guides explain the key parts of the template in more detail.

Risk register FAQs

What is a risk register?

A risk register is a project document used to record potential risks, assess their likelihood and impact, assign owners and track the actions being taken to manage them.

What is the difference between a risk and an issue?

A risk is something that might happen. An issue is something that has already happened. For example, “the supplier may miss the delivery date” is a risk. “The supplier has missed the delivery date” is an issue.

Who should update the risk register?

The project manager usually maintains the risk register, but risk owners should provide updates on their own risks. The project manager should not have to invent progress updates for risks owned by other people.

Who should own a project risk?

The risk owner should be the person best placed to monitor, manage or escalate the risk. This may be the project manager, but it could also be the sponsor, technical lead, supplier manager, business owner or another responsible person.

What is risk severity?

Risk severity is the overall rating of a risk, usually based on likelihood and impact. A simple risk register may use Low, Medium and High severity ratings.

What is the difference between mitigation and contingency?

Mitigation is action taken now to reduce the likelihood or impact of a risk. Contingency is the action you will take if the risk actually happens.

How many risks should be in a risk register?

There is no perfect number. A small project may have only a handful of risks. A large project may have many more. The key is that the register should include meaningful risks that need active management, not every vague worry anyone has ever mentioned.

When should a risk be closed?

A risk can be closed when it is no longer relevant, no longer possible, the project has passed the risk point, or the risk has happened and is now being managed as an issue.

Summary

A project risk register is a practical tool for managing uncertainty. It helps you record risks, assess severity, assign ownership and track action. In Excel, it can be simple, visible and easy to update, provided the spreadsheet is used properly.

The most useful risk registers are clear, current and action-focused. They do not just list risks. They help the project team decide what needs attention, who is responsible and what will happen next.