Search “project risk register template” and most results assume a project office: fifteen fields, a five tier scoring matrix, a tab for retired risks, and a column for the committee that signed off on the methodology. A six person team two weeks into a product launch does not have a committee. It needs a list that says what might go wrong, how bad it would be, and who is watching it.
This guide gives you a project risk register template with seven fields, a worked example with four risks and the scores that prove the math, and the habit that keeps the register alive past week one instead of dying in a folder nobody reopens.
What a risk register is for (and who does not need one)
A risk register is a running list of things that might happen to a project, rated by how likely they are and how much damage they would do if they did. It is not a task list and it is not a postmortem. A task list tracks what has to get done; a risk register tracks what could stop those tasks from getting done on time.
The point of writing a risk down before it happens is simple: a risk named in week one has an owner and a plan by week three. A risk nobody named shows up as a surprise in week six, right when it is most expensive to fix. That is the whole argument for the extra fifteen minutes it takes to fill one in.
A risk register is one of several small systems that keep a project visible without a daily status meeting; our business systems guide covers the other seven recurring systems founders end up building as the team grows.
Not every project needs a formal register. A solo founder shipping a two week project is both the only stakeholder and the only person who can act on a risk, so a mental note usually covers it. A register earns its place once more than one person depends on the outcome, the project runs longer than a few weeks, or a single missed date would be expensive to recover from. If that describes your project but you have not scoped it yet, start with our project plan template, since a risk register only makes sense once there is a plan to compare it against.
The 7 fields worth tracking
Seven fields cover what a small team actually needs. Enterprise templates add more, including impact categories, mitigation cost estimates, residual risk after response, and a column for the risk owner’s manager, because they are built for audits, not for a team trying to ship on time.
| Field | What goes in it |
|---|---|
| Risk ID | A short code (R1, R2, R3) so the team can reference a risk in conversation without retyping the full description every time. |
| Description | One sentence describing what could happen, not what you are worried about in general. “The supplier ships the launch batch late” works. “Supply chain issues” does not. |
| Likelihood | A rating from 1 to 5 for how likely this is to actually happen before the project ends. |
| Impact | A rating from 1 to 5 for how much it would hurt if it did happen, in time lost, money lost, or scope cut. |
| Score | Likelihood multiplied by impact. This is the number that decides what gets attention first. |
| Owner | One person, not a team and not a department, who watches this risk and reports on it. |
| Response | What the owner does if the risk starts to happen, decided before the crisis, not during it. |
How to score likelihood and impact without a workshop
Most risk scoring advice assumes a room full of people debating probabilities for an afternoon. A small team does not have an afternoon, and the debate rarely changes which risks get attention anyway. Rate likelihood on how often something like it has actually happened to this team or a similar one before, and rate impact on what it would cost in the three things a small project actually tracks: the deadline, the budget, and the scope.
- Score likelihood from the base rate, not the worst case. If a supplier has shipped late twice in the last five orders, that is a 3, not a 5. Save 5 for something that has already started happening.
- Score impact from what actually breaks. A one day slip that nobody outside the team notices is a 1 or 2. A slip that pushes a client deadline or costs a contracted penalty is a 4 or 5.
- Multiply, then sort by score, not by gut feeling. A 2 likelihood and 5 impact risk (score 10) deserves more attention than a 4 likelihood and 2 impact risk (score 8), even though the second one feels more urgent because it comes up more often in conversation.
- Treat 1 to 6 as low, 7 to 14 as medium, and 15 to 25 as high. Review every medium and high risk weekly. Check that low risks still belong on the list and move on; they rarely need a response plan yet.
A worked example: product launch, week 3 of 10
Here is how the seven fields look filled in for a six person team ten weeks from launching a physical product. Use it as a reference, then replace it with your own risks.
| Risk ID | Description | Likelihood | Impact | Score | Owner | Response |
|---|---|---|---|---|---|---|
| R1 | The supplier ships the launch batch late | 3 | 4 | 12 | Ops lead | Confirm the backup supplier by the end of week 4; ask the primary supplier for a partial early shipment of the first production run. |
| R2 | The lead engineer is unavailable during the final build week | 2 | 5 | 10 | Engineering lead | Cross-train a second engineer on the critical path task now, before the risk becomes urgent. |
| R3 | Marketing assets arrive late from the freelance designer | 4 | 2 | 8 | Marketing lead | Set an internal deadline five days ahead of the real one; keep an in-house fallback template ready. |
| R4 | The app store rejects the submission on first review | 2 | 4 | 8 | Product lead | Submit ten days before launch so there is time for one resubmission cycle. |
Three of the four risks land in the medium band, and one, the supplier delay, sits at the top of it. That is the risk the ops lead checks every few days instead of once a week, since a score of 12 is close enough to the high band that a small change in either likelihood or impact would push it over.
How often to review it without turning it into a meeting
Review the register once a week, in the same meeting where the team already checks project status, not as a separate standing item. A ten minute pass covers it: add anything new, update a score if the likelihood or impact changed, and close out anything that no longer applies.
Between weekly reviews, the owner field is what keeps a risk from going quiet. Pair it with a RACI chart if the project already has one, so the risk owner lines up with whoever is already accountable for that part of the work instead of creating a second layer of ownership to track.
Running several projects at once and keeping the register in a shared document starts to show cracks once a team passes four or five active projects. At that point the overhead is usually the sign to move risk tracking into the same tool the team already uses for tasks, rather than maintaining a separate document nobody remembers to open. Our guide to choosing project management software covers a five question filter for picking one without paying for features a small team will never touch.
Common mistakes that turn a risk register into a graveyard
- Writing it once at kickoff and never opening it again. A register from week one describes week one. By week six half the risks have changed and the real ones are not on the list.
- Scoring every risk a 4 or 5 to look thorough. If everything is high priority, the score stops helping anyone decide what to look at first, and the team is back to gut feeling.
- Leaving the owner field blank or filling it with a team name. A risk owned by “the team” is owned by nobody. Someone specific has to be the person who notices if it starts to happen.
- Tracking risks that already happened. Once something has happened, it is an issue, not a risk. Move it to an issue log or a blocker list instead of leaving it cluttering the register.
- Adding a response plan only after the risk hits. The response column exists so the team is not improvising under pressure. Write it while the risk is still hypothetical, when there is time to think it through.
Frequently asked questions
What should a project risk register include?
A project risk register should include seven fields: a risk ID, a short description, likelihood and impact rated from one to five, a score that multiplies the two, an owner, and a response plan. Skip the extra columns that enterprise templates add for governance committees and audit trails a small team will never use.
How often should a small team update its risk register?
Most small teams review the register once a week, during the same meeting where they already check project status. A ten minute pass is enough: add any new risk, update the score if likelihood or impact changed, and close out anything that no longer applies to the project.
What counts as a high risk score?
Multiply likelihood by impact, both rated one to five, for a score between one and twenty five. Treat one to six as low, seven to fourteen as medium, and fifteen and above as high. A high score does not mean the project will fail; it means that risk needs a response plan this week, not next month.
Who should own a risk on the register?
One person, never a team or a department. A risk owner does not have to fix the problem alone, but they are the one person who reports on it and makes sure the response plan actually happens. If two names end up in the owner field, the risk has no real owner yet.
Is a risk register the same as an issue log?
No. A risk register tracks things that might happen and have not happened yet, rated by likelihood and impact before the fact. An issue log tracks problems that already happened and now need a fix. Many small teams keep both in the same document, with an item renamed from risk to issue the day it occurs.
The bottom line
A risk register earns its place the first time a score 12 risk gets caught in week three instead of surfacing as a surprise in week eight. Seven fields, five minutes per risk to fill in, and a ten minute weekly pass are what separate a register that works from the fifteen field spreadsheet nobody opens after kickoff.
