Risk Register Template: How to Build and Use One
A simple risk register template with likelihood, impact, owner and mitigation columns, plus a 15-minute weekly habit that keeps it current and useful.
A risk register is a single table that lists what could go wrong, how likely it is, how badly it would hurt, who owns it and what you are doing about it. Build one in a spreadsheet with seven columns, score each risk from 1 to 5 on likelihood and impact, and review it for 15 minutes every week. The review habit matters more than the template.
What a risk register is for
A risk register exists to force three decisions: which risks deserve your attention, who is responsible for each one, and what you will do before the risk happens instead of after.
It is not a compliance document. It is not a list of every fear someone had in a brainstorm. If it does not change what your team does this week, it is decoration.
Most small teams skip it because it sounds like enterprise project management. That is a mistake. Small teams have less slack, so one missed dependency costs a larger share of the plan. A founder with 8 people and 7 months of cash does not have room for a surprise.
The template
Copy this into a spreadsheet. Seven columns is enough.
| ID | Risk (cause, event, effect) | Likelihood (1-5) | Impact (1-5) | Score | Owner | Mitigation and next step | Trigger | Review date |
|---|---|---|---|---|---|---|---|---|
| R1 | Our only developer leaves, so the v2 launch slips | 2 | 5 | 10 | Dana | Document deploy process; line up a contractor | Resignation or burnout signs | Nov 21 |
A few notes on each column.
- Risk: Write it as cause, event, effect. "Supplier delay" is vague. "Our packaging supplier misses the March 3 delivery, so we ship late to wholesale customers" is something you can act on.
- Likelihood and Impact: Use 1 to 5 scales. Keep the definitions in a small legend (below).
- Score: Likelihood multiplied by impact. Range is 1 to 25.
- Owner: One named person, not a team and not "TBD."
- Mitigation and next step: One concrete action with a date, not a philosophy.
- Trigger: The early warning sign that the risk is becoming real.
- Review date: When someone will look at this row again.
Scoring legend
Make the scales specific to your business so two people score the same risk the same way.
| Score | Likelihood | Impact (example for a 10-person company) |
|---|---|---|
| 1 | Under 5% in the next quarter | Under $2,000 or less than 1 day lost |
| 2 | 5 to 20% | $2,000 to $10,000 or up to 1 week lost |
| 3 | 20 to 40% | $10,000 to $30,000 or 2 to 3 weeks lost |
| 4 | 40 to 70% | $30,000 to $100,000 or a month lost |
| 5 | Over 70% | Over $100,000 or a missed launch or lost key customer |
Adjust the dollar figures to your scale. The point is that "5" means the same thing in every row.
Score bands
- 15 to 25: Act now. Weekly attention until it drops.
- 8 to 14: Active mitigation with a named owner.
- 1 to 7: Watch. Review monthly.
Step-by-step: build your first register in one hour
1. Pick the scope
Choose one thing: a project, a launch, or the business for the next quarter. A register that covers everything covers nothing. If you run a quarterly planning cycle, scope it to the quarter. The quarterly planning process is a natural place to start.
2. Brainstorm for 15 minutes, silently
Have each person write risks on their own for 10 minutes before anyone talks. Otherwise the loudest person sets the list and the quiet person who knows the supplier problem stays quiet. Prompt with these categories:
- People: key-person dependency, hiring delays, burnout
- Money: cash timing, a large customer paying late, cost overruns
- Customers: churn, a concentration problem, a shift in demand
- Suppliers and tools: single points of failure, price increases
- Delivery: scope, estimates, dependencies between teams
- External: regulation, platform changes, competitors
3. Rewrite each risk as cause, event, effect
Cut the list to 10 to 20 items. Merge duplicates. Drop anything you cannot influence or that is so remote it has no action attached.
4. Score as a group
Score likelihood first, then impact, out loud. If two people differ by more than one point, ask each to explain. That disagreement is usually where the useful information is. Do not spend more than a minute per risk.
5. Assign owners and write the next step
The owner is the person who will notice the trigger and raise it, not necessarily the person who fixes it. Write a next step that starts with a verb and has a date: "Get a second quote from a backup supplier by Nov 28."
6. Sort by score and look at the top five
Those five are your agenda. Everything else is background.
Worked example: a 12-person e-commerce brand
Take a company with $3.2 million in annual revenue, 12 employees and a plan to launch a new product line in 14 weeks. Revenue from the new line is forecast at $400,000 in the first year. The founder builds a register in an hour. After scoring, the top five look like this:
| ID | Risk | L | I | Score | Owner | Mitigation |
|---|---|---|---|---|---|---|
| R1 | Sole manufacturer misses the production date, so launch slips 4+ weeks and we lose the holiday window (about $90,000 of forecast sales) | 3 | 5 | 15 | Priya (ops) | Get a sample-run date in writing; qualify a second manufacturer by Dec 5 |
| R2 | Ad costs rise 30% during Q4, so launch customer acquisition cost exceeds the $38 target | 4 | 3 | 12 | Marcus (marketing) | Set a CAC ceiling of $48; pre-build an email launch to lean on owned channels |
| R3 | Our one warehouse lead is out during launch month, so fulfillment backs up | 2 | 4 | 8 | Priya | Cross-train one person by Nov 30 |
| R4 | Product page developer is stretched, so site is not ready 2 weeks before launch | 3 | 3 | 9 | Jon (founder) | Lock the page spec by week 4; freeze changes after week 8 |
| R5 | Cash dips under 6 weeks of runway after the inventory deposit | 2 | 5 | 10 | Jon | Negotiate 30% deposit instead of 50%; set a weekly cash check |
Here is what changed because of the register. The founder had been focused on the product page and ad creative. The register put the manufacturer at the top, which led to a conversation that revealed the supplier had never confirmed a production slot. A written date came back 3 weeks later than assumed. Because the team learned this in week 2 and not week 10, they had time to qualify a backup. The mitigation cost about $1,500 in samples. The risk it covered was roughly $90,000.
That is the real return on a register: not tidy documentation, but surfacing a thing nobody was looking at while there is still time to act.
The habit that keeps it current
A register fails the same way in most teams: someone builds it carefully, then nobody opens it again. Fix that with a small, fixed routine.
Weekly: 15 minutes, inside an existing meeting
Add a standing item to your weekly team meeting agenda. Do not schedule a new meeting. Cover only:
- The top five risks by score
- Did any trigger fire this week?
- Did any score change? Why?
- Any new risk someone noticed?
Each owner gives a one-sentence update. If an owner has nothing to say twice in a row, the risk is either dead or poorly owned.
Monthly: 30 minutes, deeper cleanup
Fold this into your monthly business review:
- Close risks that no longer apply
- Move risks that happened into your task tracker as issues
- Re-score everything against the legend
- Add two or three new risks from the past month
- Check that every row has an owner and a dated next step
Quarterly: rebuild the top of the list
Once a quarter, redo the brainstorm for 15 minutes. The risks that mattered in January are rarely the ones that matter in April.
Keep it where people already work
Put the register in the tool your team opens daily. A spreadsheet pinned in your team channel works. A document nobody can find does not. Link the top five risks from your weekly planning page so they are visible without effort.
Common mistakes
Mistake 1: Writing vague risks
"Market changes" cannot be owned, scored or mitigated. Fix it by writing cause, event and effect, and by asking "what would we do differently if this were certain?" If the answer is nothing, delete the row.
Mistake 2: Scoring everything as a 3
When the team is uncomfortable, they cluster scores in the middle. Then the register ranks nothing. Force a spread: at most a third of your risks can share any single likelihood score. Use the legend with real numbers.
Mistake 3: Mitigations that are really intentions
"Monitor supplier" is not a mitigation. "Call the supplier every Friday until the sample run ships" is. If the next step does not have a verb, a person and a date, it will not happen.
Mistake 4: Letting the register grow forever
A register with 70 rows is a graveyard. Cap active risks around 20. Anything under a score of 5 that has not moved in two months gets archived to a separate tab.
Mistake 5: Confusing risks with tasks or opinions
"Finish the website" is a task. "We have no QA person" is a fact. The risk is what that fact could cause: "Bugs reach customers in week one, so refunds eat 5% of launch revenue." Keep tasks in your execution plan and risks in the register.
Where the register connects to the rest of your planning
A risk register is more useful when it feeds other decisions.
- Scope: Many project risks are scope risks in disguise. If a risk keeps rising, check whether you need to manage scope creep.
- Scenarios: If a single risk could reshape your plan, such as losing your largest customer, build a short scenario plan instead of relying on a single row.
- Postmortems: When a risk becomes real, run a root cause review. Then add the lesson as a new risk or a better trigger.
Key takeaways
- A useful risk register has seven columns: risk, likelihood, impact, score, owner, mitigation and next step, and review date. Add a trigger if you can.
- Write each risk as cause, event and effect so it can be scored, owned and acted on.
- Define your 1 to 5 scales with real dollar and time thresholds so the scores mean the same thing to everyone.
- Keep it to 10 to 20 active risks and spend your attention on the top five.
- Review it for 15 minutes weekly inside an existing meeting, and clean it up monthly. The habit is what makes it work.
- Every mitigation needs a verb, a named person and a date, or it is only an intention.
Frequently asked questions
- What should a risk register include?
- At minimum: a short description of the risk, likelihood, impact, a score, an owner, a mitigation action, and a review date. Add a trigger (the early warning sign) if you can. Anything beyond that tends to make the register harder to maintain without making decisions better.
- How many risks should be in a risk register?
- For a small team or a single project, 10 to 20 active risks is plenty. If you have 60, nobody reads it and the top five get buried. Close or merge anything that has not moved in two review cycles.
- How often should you update a risk register?
- Review it weekly for 10 to 15 minutes during an existing team meeting, and do a deeper cleanup monthly. Update it immediately when a trigger fires or a risk turns into an actual problem.
- What is the difference between a risk and an issue?
- A risk is something that might happen. An issue is something that already has. When a risk occurs, move it out of the register and into your issue or task tracking, then record what you learned.
- Do small businesses need a risk register?
- Yes, if you have a launch, a hire, a big customer or a cash constraint that could hurt you. A one-page register in a spreadsheet takes an hour to set up and often surfaces the one dependency that would have caught you off guard.
Related playbooks
How to Run a Project Kickoff Meeting: Step-by-Step Guide
Run a project kickoff meeting that locks in scope, owners, risks, and success criteria. Includes a pre-work checklist, 60-minute agenda, and example.
How to Write a Project Brief Template That Aligns Teams
A lean project brief template with five elements that stop scope misalignment before work starts. Includes a realistic worked example and the most common mistake to avoid.
Gantt Chart vs Kanban Board Planning: Which to Use
Learn when to use a Gantt chart vs a Kanban board for project planning. Side-by-side comparison, a worked example, and a 3-question decision rule.
How to Build a Project Roadmap Template for Small Teams
A lightweight project roadmap template for small teams under 20: how to set milestones, sequence work, assign ownership, and communicate progress clearly.