Every project carries uncertainty. A supplier might miss a delivery date, a key team member could leave mid-build, or a regulatory change could rewrite your requirements overnight. The difference between teams that navigate these surprises and teams that get blindsided by them usually comes down to one document: the risk register.
A risk register is not a bureaucratic checkbox exercise. At its best, it is a living record of what could go wrong, how bad it would be, and what you are doing about it. It gives your team a shared view of the threats ahead and a clear plan for handling them.
This guide walks you through building a risk register from scratch, step by step, using a realistic project example. By the end you will have a working register you can use on your next project immediately.
What is a risk register?
A risk register is a structured document (or tool) that captures every identified risk on a project along with its key attributes: a description, a probability score, an impact score, an owner, a treatment strategy, and the actions being taken to address it.
Think of it as a centralised inventory of everything that could derail your project, paired with your game plan for each item. It serves three purposes at once: it is a planning tool (what could go wrong?), a prioritisation tool (which risks matter most?), and an accountability tool (who is handling what?).
Risk registers go by different names depending on your industry. Construction teams might call it a risk log, IT teams may call it a risk tracker, and enterprise organisations sometimes fold it into a broader risk management plan. The format varies, but the core idea is the same.
Why your project needs one
Without a risk register, risk management tends to happen informally. Someone mentions a concern in a meeting, a few people nod, and then it slips through the cracks because nobody wrote it down, scored it, or assigned it to anyone.
A register changes that dynamic in several ways. It makes risks visible to the whole team, not just the person who spotted them. It forces you to assess each risk consistently using a shared scoring method, so you can compare risks against each other and prioritise the ones that need attention first. It assigns clear ownership, so every risk has someone responsible for watching it and taking action. And it creates a record you can review in each project meeting, which keeps risk management active rather than something you did once at kickoff and then forgot about.
Research from the Project Management Institute consistently shows that projects with formal risk management practices are more likely to meet their schedule and budget targets. That is not because those projects face fewer problems. It is because they spot problems earlier and have plans ready when things go sideways.
The 7 fields every risk register needs
Before you start identifying risks, you need to set up the structure of your register. Every effective risk register captures these seven fields for each entry:
Field |
What it captures |
Example |
|---|---|---|
Risk ID |
A unique code for easy reference |
R-001 |
Description |
A clear, specific statement of what could go wrong |
Key developer leaves during the database migration phase |
Probability |
How likely is it to happen? (1 to 5 scale) |
3 (Possible) |
Impact |
How bad would it be if it did? (1 to 5 scale) |
4 (Major) |
Risk Score |
Probability × Impact, giving you a priority ranking |
12 (High) |
Owner |
Who is responsible for monitoring and managing this risk? |
Sarah Chen, Tech Lead |
Treatment Strategy |
Your approach: avoid, mitigate, transfer, or accept |
Mitigate |
Some teams add additional fields like risk category (technical, financial, schedule), target date, or residual score (the risk level after your mitigations are in place). These are valuable additions, but the seven fields above are the essential foundation.
Tip: Keep your risk descriptions specific. "Technical problems" is too vague to act on. "Legacy API fails to handle the new data format during integration testing" tells you exactly what to watch for and who should care.
Step 1: Identify your risks
The first and most important step is getting risks out of people's heads and into the register. Most teams underestimate this phase, identifying only the obvious risks and missing the ones that actually cause the most damage.
The most effective approach is running a dedicated risk identification session with your core project team. Block 60 to 90 minutes, get the right people in the room (or on the call), and work through the project systematically.
A useful structure is to walk through the project timeline phase by phase and ask: what could go wrong at each stage? For a website redesign project, you might work through discovery, design, development, testing, launch, and post-launch. For a construction project, you would walk through planning, procurement, groundwork, build, fit-out, and handover.
Some prompts that surface risks people tend to miss:
- People risks: What happens if someone critical is unavailable? Do we have single points of failure on the team?
- Dependency risks: Where are we relying on third parties, approvals, or deliverables from outside the team?
- Technical risks: Which parts of the work involve technology we have not used before, or integrations that are untested?
- Scope risks: Where might requirements change or expand? Which stakeholders tend to add late requests?
- External risks: Are there regulatory, market, or environmental factors that could affect us?
- Budget risks: Where are our cost estimates least certain? What could cause overruns?
Do not filter or judge risks during this phase. Capture everything. You will score and prioritise them in the next step, and some risks that feel minor at first turn out to be significant once you think through the consequences.
For our example, let us say we are managing an office relocation project. After a brainstorming session, the team identifies these risks:
ID |
Risk |
|---|---|
R-001 |
Building permit approval delayed beyond the planned start date |
R-002 |
IT infrastructure not ready on move-in day, preventing staff from working |
R-003 |
Furniture supplier delivers late due to supply chain issues |
R-004 |
Key project manager leaves during the relocation |
R-005 |
Fit-out costs exceed budget due to unforeseen building condition issues |
R-006 |
Staff resistance to new open-plan layout reduces productivity post-move |
Step 2: Assess probability and impact
Now score each risk on two dimensions: how likely it is to occur (probability) and how severe the consequences would be if it did (impact). The standard approach is a 1 to 5 scale for each.
Probability scale:
Score |
Label |
Meaning |
|---|---|---|
1 |
Rare |
Very unlikely to happen; no history of occurrence |
2 |
Unlikely |
Could happen but not expected |
3 |
Possible |
Has happened before or could reasonably happen |
4 |
Likely |
More likely than not to occur |
5 |
Almost Certain |
Expected to happen; would be surprising if it did not |
Impact scale:
Score |
Label |
Meaning |
|---|---|---|
1 |
Negligible |
Minimal effect; absorbed within normal operations |
2 |
Minor |
Small delay or cost increase; manageable |
3 |
Moderate |
Noticeable effect on schedule, cost, or quality |
4 |
Major |
Significant disruption; requires senior attention |
5 |
Catastrophic |
Project-threatening; could cause failure or major loss |
Scoring should be a team conversation, not one person's guess. Different team members bring different perspectives, and the discussion itself is often more valuable than the final number. When people disagree, it usually means someone knows something others do not.
Let us score our office relocation risks:
ID |
Risk |
Prob. |
Impact |
Score |
|---|---|---|---|---|
R-001 |
Building permit delayed |
3 |
5 |
15 |
R-002 |
IT infrastructure not ready |
4 |
4 |
16 |
R-003 |
Furniture delivery late |
3 |
3 |
9 |
R-004 |
Key PM leaves |
2 |
4 |
8 |
R-005 |
Fit-out costs exceed budget |
3 |
4 |
12 |
R-006 |
Staff resistance to new layout |
4 |
2 |
8 |
Step 3: Prioritise using a risk matrix
Once every risk has a score, you can see which ones need your attention first. Multiply probability by impact and you get a score from 1 to 25. Group these into risk levels:
Score Range |
Risk Level |
What it means |
|---|---|---|
1 to 5 |
Low |
Monitor periodically. No immediate action needed. |
6 to 11 |
Medium |
Plan a response. Review regularly. |
12 to 19 |
High |
Needs active management and a clear mitigation plan. |
20 to 25 |
Critical |
Demands immediate attention. Escalate to senior leadership. |
In our example, R-002 (IT infrastructure, score 16) and R-001 (permit delay, score 15) are the top priorities, both falling into the High range. These are the risks that could significantly derail the project, and they need active treatment plans, clear owners, and regular review.
R-005 (budget overrun, score 12) is also High and warrants a mitigation plan. The remaining three risks are Medium, which means you should have a plan but they do not need daily attention.
Tip: A visual risk matrix (sometimes called a heat map) makes these priorities immediately obvious. When you plot risks on a 5×5 grid with probability on one axis and impact on the other, the colour coding tells the story at a glance. This is especially useful when presenting risks to stakeholders who do not want to read a spreadsheet.
Step 4: Choose a treatment strategy
For each risk, decide on your approach. There are four standard treatment strategies:
Avoid means changing your plan so the risk cannot occur. If a particular supplier is unreliable, you switch to a different one. If a technology is untested, you use a proven alternative instead. Avoidance eliminates the risk entirely, but it often means compromising on scope or approach.
Mitigate means taking action to reduce the probability or impact (or both). This is the most common strategy. For our IT infrastructure risk, mitigation might mean starting the IT setup two weeks earlier and running a full systems test before moving day.
Transfer means shifting the financial or operational impact to a third party. Insurance is the classic example. Contractual penalties for late delivery shift risk to a supplier. Outsourcing a specialised task to an expert firm transfers technical risk.
Accept means acknowledging the risk and choosing to deal with the consequences if it happens, usually because the cost of mitigation outweighs the potential impact. You might accept a low-probability risk and set aside a contingency budget just in case.
Step 5: Assign owners and define actions
Every risk needs an owner: one person who is responsible for watching it and making sure the treatment plan gets executed. This is not necessarily the person who does all the work. The owner is the person accountable for ensuring the risk is managed.
For each risk with an active treatment strategy (anything except "accept and monitor"), define specific actions with deadlines and assignees. Actions should be concrete and measurable:
Risk |
Owner |
Strategy |
Key Actions |
|---|---|---|---|
R-002: IT not ready |
James (IT Lead) |
Mitigate |
Begin IT setup 2 weeks early (Apr 1). Run full systems test by Apr 10. Have backup connectivity plan documented by Apr 5. |
R-001: Permit delayed |
Maria (PM) |
Mitigate |
Submit application with 4-week buffer (Mar 15). Weekly follow-up calls with council. Identify alternative space as contingency. |
R-005: Budget overrun |
Maria (PM) |
Mitigate |
Commission building survey before signing lease. Add 15% contingency to fit-out budget. Get fixed-price quotes where possible. |
The key is specificity. "Keep an eye on it" is not an action. "Call the permit office every Tuesday and update the team at Wednesday standup" is.
Step 6: Review and update regularly
A risk register that sits untouched in a shared drive is worthless. The whole point is that it stays current as your project evolves. New risks emerge, existing risks change in probability or impact, and actions get completed (or missed).
Set a review cadence that matches your project pace. For most projects, a weekly review during the team standup or project meeting works well. For fast-moving projects, twice a week might be appropriate. For longer, slower projects, fortnightly might be enough.
During each review, work through three questions:
- Has anything changed? Have any scores gone up or down based on new information? Should any risks be closed?
- Are actions on track? Are the mitigation actions progressing? Are any overdue?
- Are there new risks? Has anything happened since the last review that introduces a new threat?
Update the register during the meeting, not afterwards. If you leave it to later, it does not get done.
Spreadsheet or dedicated tool?
Many teams start with a spreadsheet, and that is perfectly fine for small projects with a few risks. But spreadsheets have well-known limitations that become painful as your project grows: version control issues when multiple people edit the same file, no automatic score calculation, no way to track action completion, and no visual heat map.
A dedicated risk management tool like Riskjar solves these problems. Risks are scored automatically using a 5×5 matrix, actions have assignees and due dates with completion tracking, the heat map updates in real time, and everyone on the team sees the same current data. You also get features like review scheduling, risk categories, export to share with stakeholders, and a full audit trail of changes.
If you are managing more than one project, or if your team has more than three or four people, the switch from spreadsheet to a purpose-built tool pays for itself quickly in time saved and risks that do not fall through the cracks.
Ready to build your first risk register? Try Riskjar free and go from blank page to a working risk register in five minutes. No spreadsheet wrangling required.
Common mistakes to avoid
Having built risk registers across many projects, a few patterns consistently trip teams up.
Vague descriptions are the most common problem. "Budget risk" tells you nothing. "Contractor invoices exceed approved budget by more than 10% due to scope changes in the electrical work" gives you something you can actually manage.
Set-and-forget syndrome kills more risk registers than anything else. If the register is only updated at project kickoff and then lives in a drawer, it provides zero value. Risk management is a continuous activity, not a one-time event.
No clear ownership means nobody is accountable. If a risk is everyone's responsibility, it is nobody's responsibility. Every risk needs exactly one owner.
Ignoring positive risks is a missed opportunity. Not all risks are threats. Some are opportunities: a supplier might deliver early, a competitor might exit the market, or a new technology might simplify your approach. Track these too, with strategies to exploit or enhance them.
Over-engineering the register with dozens of fields and complex scoring formulas makes it intimidating and reduces adoption. Start simple with the seven fields described above. You can always add complexity later if the team needs it.
Putting it all together
A risk register is one of the highest-leverage tools in project management. It takes a few hours to set up, a few minutes per week to maintain, and it gives your team a structured, shared approach to handling uncertainty.
Here is the process in summary: identify risks as a team, score each one for probability and impact, prioritise using the risk matrix, choose a treatment strategy, assign owners and define concrete actions, then review and update regularly throughout the project.
Start with your next project. Get the team together for an hour, work through the steps above, and you will have a working risk register by the end of the session. The first time a risk you identified early gets caught and handled before it becomes a crisis, the value will be obvious.