How to Build a Project Risk Register (With Examples)

Every project carries risks: a supplier who might deliver late, a key person who might be out sick during go-live, a permit that might take longer than expected. Most teams know about these risks in a vague way. The problem is that a risk nobody wrote down usually has nobody watching it, and it tends to surface at the worst possible moment.

A risk register fixes that. It is a short, living list of what could go wrong, how likely and how serious each item is, who is watching it, and what you plan to do about it. This guide walks through how to build one that your team will actually keep up to date, with example entries for construction, healthcare operations and small business projects.

What is a project risk register?

A risk register (sometimes called a risk log) is a table of identified project risks. Each row describes one risk and records the information you need to manage it: its likelihood, its impact, an owner, a response plan and a date to review it.

It is not the same as an issue log. A risk is something that might happen. An issue is something that already has. When a risk actually occurs, you close it in the register and handle it as an issue, often by adjusting tasks and dates in your schedule.

The columns your risk register needs

You can add many fields, but a register with too many columns gets abandoned. These are the ones that earn their place:

• ID – a short reference such as R-01 so people can mention a risk in meetings and comments.
• Risk description – what could happen, why, and what it would affect (more on wording below).
• Category – for example supply, people, technical, weather, financial, regulatory or client. Categories help you spot clusters.
• Likelihood – how probable it is, usually on a 1–5 scale or Low / Medium / High.
• Impact – how much damage it would do to time, cost, quality or safety, on the same scale.
• Score or rating – likelihood combined with impact, so you can sort by priority.
• Owner – one named person who watches the risk and triggers the response. Not a department, not "the team".
• Response / mitigation plan – the concrete action you will take now, or the fallback if it happens.
• Due date or review date – when the mitigation should be done or when the risk will be checked again.
• Status – open, being mitigated, closed, or occurred (moved to issues).

How to build a risk register in 6 steps

1. Identify risks with the people doing the work

Hold a short session with the people closest to the work: site supervisors, shift leads, the person handling suppliers, whoever will actually feel the problems. Walk through the schedule phase by phase and ask, "What could stop or slow this down?" Also look at the things that went wrong on similar past projects; your own history is often the best source.

Useful prompts include:

• Which tasks depend on someone outside the team (suppliers, clients, inspectors, other departments)?
• Which tasks rely on a single person or a single piece of equipment?
• Where are durations based on hope rather than experience?
• What external factors (weather, approvals, peak season) could change the plan?

2. Write each risk as cause, event and effect

Vague entries like "delays" or "budget" are hard to act on. A clearer format is: Because of [cause], [event] may happen, which would [effect].

• Weak: "Supplier problems."
• Better: "Because the window supplier has a long lead time and a single factory, delivery may slip, which would delay interior finishing and the handover milestone."

Writing risks this way makes the owner and the response much easier to choose, because you can see exactly which link in the chain you can break.

3. Rate likelihood and impact

Use a consistent scale and agree on what each level means for your project. For example, on impact: Low means a delay of a day or two with no cost change, Medium means a delay that moves a milestone or a noticeable cost overrun, High means it threatens the deadline, the budget or safety. On likelihood: Low means unlikely given what you know, Medium means plausible, High means you would be surprised if it did not happen.

Multiply or combine the two to get a rating. A High-likelihood, High-impact risk goes to the top of the list; a Low/Low risk may simply be accepted and monitored. The exact scoring method matters less than applying it the same way every time.

4. Choose a response for each risk

There are four classic ways to respond to a threat:

• Avoid – change the plan so the risk no longer applies, such as choosing a different supplier or method.
• Reduce – lower the likelihood or impact, such as ordering earlier, adding a backup person or building in buffer time.
• Transfer – move the consequences to someone better placed to carry them, for example through a contract term or insurance.
• Accept – decide consciously to live with it, ideally with a contingency amount or fallback ready.

Make the response specific and dated: "Order windows by 15 March and confirm the shipping date in writing" is a plan. "Monitor supplier" is not.

5. Assign one owner and a due date

Every risk needs a single owner who is responsible for watching the warning signs and carrying out the response. Give each mitigation action a due date and, where it makes sense, put it in the schedule as a real task. A mitigation that lives only in a spreadsheet tends to be forgotten; one that shows up in someone's task list for this week gets done.

6. Link risks to your schedule and budget

Risks are not separate from the plan. If a risk sits on a task that has many dependents, its real impact is larger than it first looks, because a slip there pushes everything after it. When you rate impact, check the Gantt chart: what is linked after this task, and does it lead to a milestone? Likewise, if you accept a risk, consider setting aside a contingency line in the project budget so that the cost of the fallback is not a surprise.

Risk register examples by project type

Construction and field teams

• R-01, Weather (Likelihood: Medium, Impact: High): Because the foundation pour is scheduled in the rainy season, heavy rain may stop concrete work, which would delay framing. Response: reduce – add buffer before the framing start, line up an alternative pour date with the supplier. Owner: site supervisor.
• R-02, Supply (Medium / Medium): Because a specialist fitting has a long lead time, delivery may arrive after installation is due, which would hold up inspections. Response: reduce – place the order at contract signing and confirm shipping dates weekly. Owner: procurement lead.

Healthcare operations

• R-03, People (Medium / High): Because staff training for a new scheduling process falls during a busy period, some staff may miss sessions, which would slow adoption after go-live. Response: reduce – offer two extra sessions and name a floor champion per shift. Owner: operations manager.
• R-04, Technical (Low / High): Because the equipment move depends on a vendor installation window, the vendor may reschedule, which would push back the room reopening. Response: accept with fallback – keep the existing room available until sign-off. Owner: facilities coordinator.

Small business projects

• R-05, People (High / Medium): Because only one person knows the online store setup, their absence may stall the launch. Response: reduce – document the setup steps and pair a second person on key tasks. Owner: owner/manager.
• R-06, Financial (Medium / Medium): Because packaging prices can change between quote and order, costs may exceed the budget. Response: transfer/reduce – lock the price in the order confirmation and keep a small contingency. Owner: finance lead.

These are illustrations of the format, not benchmarks. Your own ratings will depend on your project, location and team.

Keeping the register alive

A risk register written at kickoff and never opened again is just paperwork. A few habits keep it useful:

• Review it on a fixed rhythm. Add a five-minute risk check to your weekly project meeting: what is new, what changed rating, what can be closed.
• Review it at milestones. Each phase brings new risks and retires old ones.
• Watch for triggers. Note an early warning sign for major risks, such as "supplier has not confirmed the ship date by the 10th", so the owner knows when to act.
• Close risks explicitly. Mark them closed with a short note. A shorter list is easier to read and keeps attention on what still matters.
• Keep it where the team works. If the register lives in a file nobody opens on site or on the ward, it will drift out of date. Put it next to the schedule.

Common mistakes to avoid

• Listing issues as risks. If it has already happened, it belongs in the issue list and the schedule, not the register.
• Too many low-value entries. Fifty trivial risks hide the five that matter. Focus on what could really affect time, cost, quality or safety.
• Shared ownership. "Everyone" means no one. One name per risk.
• Responses without dates. A mitigation with no deadline usually turns into a good intention.
• Ignoring opportunities. Some uncertainties are positive, such as a phase finishing early. Note them too so you can take advantage.

Tracking risks alongside your Gantt chart

A spreadsheet works for a risk register, but it separates the risks from the tasks and dates they affect. Keeping both in one project tool makes the weekly review faster: you can open a risk, see the linked part of the schedule, check its owner and update the plan in one place.

In GanttMaster, each project has a risk module where you can record a risk category, likelihood, impact, mitigation plan, owner and due date, next to budget and expense tracking and an interactive Gantt chart with Finish-to-Start, Start-to-Start and Finish-to-Finish dependencies. Mitigation actions can be added as tasks or subtasks, assigned to a team member, and they show up in the Today view with reminders when they are due.

Quick risk register checklist

• Each risk is written as cause, event and effect.
• Likelihood and impact use one agreed scale.
• Every risk has one named owner.
• Every response is specific and has a date.
• High-rated risks on tasks with many dependents are checked against the schedule.
• The register is reviewed weekly and at every milestone.