Risk Register: Template, Example, and How to Build One (2026)
A risk register is a single list of everything that could go wrong on a project, with a plan for each item. For every risk you note what it is, how likely it is, how hard it would hit, who owns it, and the plan. Kept up to date, it is the one document that turns "I have a bad feeling about this" into a tracked decision the whole team can see.
This guide gives you the complete version: what a risk register is, the fields that belong in it, a worked example to copy, and a five-step build process. There is an interactive builder and template below that scores and sorts your risks as you add them, then exports the whole thing as a spreadsheet. No enterprise software required, and the same register works whether you run one project or fifty.
Quick answer: what a risk register is
A risk register, sometimes called a risk log, is a document that lists every identified risk on a project with the information needed to manage it. For each risk that means a description, a likelihood and impact rating, a score, an owner, a planned response, and a status. It is both a thinking tool and a tracking tool. You build it during planning, then keep it open and update it as risks change, close, or appear.
The reason it works is that most project trouble is not a surprise. Tom Kendrick's PERIL database, built from 222 troubled projects, found that the bulk of the damage traced back to a small set of recurring, foreseeable risk categories. A register is how a team writes those down before they bite, gives each one an owner, and plans the response in calm conditions, not mid-crisis.
Build your risk register
Add a risk, set how likely it is and how hard it would hit, name an owner, and pick a response. The builder scores each risk, color-codes the level, and sorts the register so the biggest risks sit on top. Copy the result out as a spreadsheet when you are done.
Risk register builder
Add a risk and the register scores it (likelihood times impact), color-codes the level, and sorts the list so the biggest risks sit on top. Set an owner, a response, and a status for each one, then copy the whole register out as a spreadsheet. Three example project risks are loaded to start.
Risk register
The score in the register is likelihood multiplied by impact, the same arithmetic a risk matrix uses to place a risk on its grid. The register and the matrix are two views of the same data, which the section below on register versus matrix explains.
A register only works if the team keeps looking at it.
Rock holds your risk register as a board or list inside the project space, so risks get reviewed in the same rhythm as the work, not in a file nobody opens. One flat price, unlimited users.
What is a risk register?
A risk register is a project management document that records identified risks and the information needed to act on each one. The PMI PMBOK Guide treats it as the central output of risk identification, a living document created early and updated throughout the project. The names vary. Some call it a risk log, others a risk registry, but the artifact is the same: one place where every risk lives with its owner and plan.
The register answers four questions for each risk. What could go wrong? How bad would it be, and how likely? Who is responsible for it? What will we do about it? A risk that cannot answer all four is not ready to be managed. The most common gap is the third question. David Hillson, author of Managing Risk in Projects, returns to ownership again and again. A risk on a list with no name next to it is a risk nobody is actually handling.
"Every risk needs a single named owner who is accountable for managing it. A risk without an owner is a risk that no one is managing." - David Hillson, paraphrased from Managing Risk in Projects
A register is not the same as a risk matrix. The matrix is a visual that ranks risks by likelihood and impact on a grid. The register is the document that carries the full detail and tracks each risk over time. Most teams build both and keep them in sync, which the comparison section below covers.
What goes in a risk register
A register can be as simple as five columns or as detailed as a dozen. The fields below are the standard risk register template. Start with the core ones and add the optional fields only if you will actually maintain them. An accurate five-column register beats an abandoned twelve-column one every time.
| Field | What it captures | Core or optional |
|---|---|---|
| Risk ID | A short code (R1, R2) so you can refer to a risk without retyping it | Core |
| Risk description | The risk written as cause and effect, not a vague worry | Core |
| Likelihood | How probable the risk is, usually rated 1 to 5 | Core |
| Impact | How damaging it would be if it happened, rated 1 to 5 | Core |
| Score | Likelihood times impact, used to rank and color-code the risk | Core |
| Owner | The one named person accountable for managing the risk | Core |
| Response | The strategy: avoid, mitigate, transfer, or accept | Core |
| Action / mitigation | The specific step that enacts the response, and who does it | Core |
| Status | Open, in progress, or closed | Core |
| Category | Grouping such as commercial, technical, resourcing, or external | Optional |
| Trigger | The early warning sign that the risk is about to occur | Optional |
| Contingency | The fallback plan if the risk happens despite mitigation | Optional |
The four responses in the Response field are the standard set. Avoid removes the cause, for example by cutting a risky feature from scope. Mitigate reduces the likelihood or the impact. Transfer moves the risk to someone else, through insurance or a contract clause. Accept means you acknowledge the risk and monitor it without acting yet. The score guides the choice: high scores call for avoid or mitigate, low scores can often be accepted.
Risk register example
Here is a filled-in register for a realistic engagement: a fixed-fee website build run by a small team over ten weeks. Six risks, each scored, owned, and given a response, sorted with the highest score on top. This is the same shape the builder above produces.
| ID | Risk | Score | Owner | Response | Status |
|---|---|---|---|---|---|
| R1 | Scope creep on the fixed bid (L4 x I4) | 16 | Account lead | Mitigate: change-order clause, log every request | Open |
| R2 | Client slow to approve designs (L4 x I3) | 12 | Project manager | Mitigate: approval deadlines in the contract | In progress |
| R3 | Client delays final payment (L3 x I4) | 12 | Founder | Transfer: milestone invoicing, pause on overdue | Open |
| R4 | Lead developer leaves mid-project (L2 x I5) | 10 | Founder | Mitigate: document weekly, cross-train a second dev | Open |
| R5 | Third-party API integration slips (L3 x I3) | 9 | Lead developer | Mitigate: spike it in week one, not week eight | In progress |
| R6 | Minor browser bugs at launch (L4 x I1) | 4 | QA | Accept: fix in the post-launch window | Open |
The ranking is the point. Scope creep tops the register at 16, so it gets the firmest contract language and the closest watch. Minor browser bugs sit at the bottom with an accept response, because spending scarce attention there would steal it from the risks that can sink the project. Each risk has one named owner, which is what turns the list from a record into a plan.
How to build a risk register in five steps
The register itself is just a table. The work is identifying real risks and keeping the document alive. These five steps produce a register the team uses, not one that gets built for a proposal and then forgotten.
- Identify the risks with the team Run a short session, ideally a pre-mortem, with the people doing the work and list what could go wrong. Pull from past projects, the project plan, and known dependencies. Write each risk as a cause and effect: "Client is slow to approve designs, which pushes the launch" beats "client problems." Kendrick's PERIL data is a useful prompt here, because most risks fall into a few categories that repeat across projects.
- Score likelihood and impact Rate each risk on likelihood and impact, usually 1 to 5, and multiply for a score. Agree the ratings as a team, because the disagreement is the valuable part. The score sorts the register so the biggest risks rise to the top and get attention first.
- Assign one owner to each risk Give every risk a single named owner who is accountable for watching it and driving the response. Not a team, one person. This is the step most registers skip, and it is the step that separates a register that works from a list that decorates a folder. A RACI matrix helps if ownership is contested.
- Choose a response and an action For each risk, pick avoid, mitigate, transfer, or accept, then write the specific action that enacts it. "Mitigate" is not a plan; "add a change-order clause and log every request" is. High-score risks need an action now. Low-score risks can be accepted and monitored.
- Review it on a cadence A register built once is wrong by week two. Pull it up at every milestone or sprint planning session and ask three questions: which risks closed, which grew, and what new ones appeared. Update the status, add the new risks, and the register stays a live picture of the project rather than a snapshot of its first week.
Risk register vs risk matrix
These two tools get confused because they use the same inputs, but they do different jobs. You use them together, not instead of each other.
A risk matrix is a visual. It plots each risk on a grid of likelihood against impact and colors the cells so the priorities jump out. It is the fastest way to see, in one glance, which risks sit in the red corner. What it does not do is track detail. A matrix cell does not hold an owner, a response, a status, or a history.
A risk register is the document. It carries the full record for each risk: the description, the owner, the response, the action, the status, and how all of those change over time. What it does not do is communicate priority at a glance the way a colored grid does.
The practical workflow is to use both. Score each risk, plot it on the matrix to set priority and have the prioritization conversation, then record and manage it in the register. The matrix is for the meeting; the register is for the months between meetings. Both run off the same likelihood and impact numbers, so keeping them in sync is a matter of using one scoring scale across the two.
Common risk register mistakes
Most registers fail in one of a few predictable ways. None of the fixes are complicated.
- Risks with no owner A risk assigned to "the team" is assigned to nobody. Every risk needs one named person accountable for it. This is the single most common reason a register tracks problems that never actually get managed.
- Building it once and never updating it A register written for a proposal and then filed is theater. The risks change every week. Without a review cadence, the register describes a project that no longer exists.
- Vague risk descriptions "Budget" is not a risk. "Client adds out-of-scope requests that erode the fixed-fee margin" is. Write each risk as a cause and an effect so the response is obvious and the owner knows what to watch for.
- A response with no action Writing "mitigate" in the response column changes nothing. The register needs the specific step that enacts the response and the person who will take it. The word is the category; the action is the work.
- Keeping it where nobody looks A register in a spreadsheet buried in a drive is out of sight and out of mind. Keep it where the work happens so it gets reviewed in the normal rhythm, not in a separate meeting that never gets scheduled.
- Treating it as a compliance checkbox A register filled in to satisfy a process, then ignored, is worse than none because it creates false confidence. The value is in the reviewing and acting, not in the existence of the document.
What we recommend at Rock
Rock is not dedicated risk software, and a risk register does not need any. The pattern we see among teams who use Rock is to keep the register where the work lives. Risks then get reviewed in the same rhythm as tasks, not in a spreadsheet nobody reopens.
In practice that is a list or board in the project space with one card per risk. Each card carries the likelihood, impact, score, owner, response, and status, the same fields as the builder above. A label or column groups cards by level, which gives the red-orange-yellow-green read of a matrix without a separate file. Because the risks sit next to the tasks they threaten, the weekly review covers them without anyone scheduling a separate risk meeting. That cadence is the whole game.
For teams running several projects in parallel, each project gets its own space and its own register, because the risks differ by engagement. Pair the register with a project charter at kickoff and the highest risks are captured before the work starts, when responses are cheapest to plan.
Free resource: the Project Management template gives you a space with boards ready to hold tasks and a risk register side by side.
Frequently asked questions
What is a risk register in simple terms?
A risk register is a list of everything that could go wrong on a project, with a plan for each item. For each risk it records a description, how likely and how damaging it is, a score, the person who owns it, and what the team will do about it. It is built during planning and updated throughout the project.
What should a risk register include?
At minimum: a risk ID, a description, likelihood and impact ratings, a score, an owner, a response (avoid, mitigate, transfer, or accept), the specific action, and a status. Optional fields include a category, a trigger that warns the risk is coming, and a contingency plan. An accurate five-field register beats an abandoned twelve-field one.
What is the difference between a risk register and a risk log?
They are the same thing. "Risk register," "risk log," and "risk registry" all refer to the document that records and tracks project risks. Different methodologies and teams prefer different names, but the artifact and its fields are identical.
What is the difference between a risk register and a risk matrix?
A risk matrix is a visual grid that ranks risks by likelihood and impact so priorities show at a glance. A risk register is the document that carries the full detail for each risk, including owner, response, and status, and tracks it over time. They use the same scores and work together: the matrix prioritizes, the register manages.
How often should you update a risk register?
Review it on a regular cadence, typically at every project milestone or sprint planning session, and update it whenever a significant risk appears or changes. The point of a register is that it stays current. A register reviewed monthly at most is usually one that has stopped being used.
Who owns the risk register?
The project manager or project lead usually owns the register as a whole and keeps it current. Each individual risk inside it has its own named owner, who is accountable for watching that risk and driving its response. The two are different roles: one maintains the document, the others manage the risks.
A risk register turns a vague sense of what could go wrong into a tracked, owned, reviewable plan. Keep the fields simple, give every risk one owner, and review it on a cadence. Rock keeps chat, tasks, and your risk register in one workspace. One flat price, unlimited users. Get started for free.
