Risk Register Example and Template (Step-by-Step Guide)

It’s the Monday status meeting. Someone mentions that the only person who understands the payment module has handed in notice. Everyone nods. Nobody writes it down. Six weeks later, the project is late and the same people say, “We saw this coming.”

A risk register fixes that. It is a simple table where you write down what could go wrong, how likely it is, how bad it would be, and who will do something about it. In this guide you’ll see a complete risk register example for an IT project, a template you can copy, and a clear way to score and respond to each risk. If you want to skip the typing, use the free Risk Register Builder and download your register as a PDF.

What Is a Risk Register?

A risk register is a living list of project risks. Each row describes one risk and what you plan to do about it. It is not a document you write once and forget. You open it every week.

A risk is something that might happen. An issue is something that already has.

That one difference matters. When a risk happens, it moves out of the register and into your issue log, and your planned response becomes real work.

The Columns Every Risk Register Needs

You don’t need twenty columns. These ten are enough for most IT projects.

Column	What to write
ID	A short code such as R1, R2
Risk description	One sentence: “If X happens, then Y.”
Cause or trigger	What would tell you this is starting to happen
Probability (1 to 5)	How likely it is
Impact (1 to 5)	How bad it is if it happens
Score	Probability multiplied by impact
Response	Avoid, mitigate, transfer or accept
Action	The specific step you will take
Owner	One named person
Status	Open, watching, closed or happened

A Risk Register Example for an IT Project

Say your team is building a customer portal with a vendor, a third-party API and a fixed launch date. Here is what a realistic register could look like. Probability and impact are each scored 1 to 5.

ID	Risk	P	I	Score	Response	Action	Owner
R1	Key developer leaves before launch	3	5	15	Mitigate	Pair a second developer on the module and write handover notes	Delivery manager
R2	Third-party API changes without notice	3	4	12	Mitigate	Pin the API version and add contract tests	Tech lead
R3	Requirements keep changing	4	3	12	Mitigate	Start formal change control and review changes weekly	Project manager
R4	Security flaw found late in testing	2	5	10	Mitigate	Run security checks every sprint, not only at the end	QA lead
R5	Test environment is not ready on time	2	4	8	Avoid	Book the environment now and confirm dates in writing	QA lead
R6	Vendor delivers a component late	2	3	6	Transfer	Add a delivery date and penalty clause to the contract	Procurement lead

Notice a few things. Every risk has one owner, not a team. Every action is something a person can do this week. And the register is sorted by score, so the biggest worries sit at the top.

How to Score Risks Without Overthinking

Multiply probability by impact. That gives a score from 1 to 25. Then use simple bands.

Score	Level	What to do
1 to 5	Low	Accept it and review monthly
6 to 11	Medium	Plan a response and review every two weeks
12 to 25	High	Act now and review every week

Your numbers will never be exact, and that’s fine. The point is to compare risks with each other, so the order is more useful than the number.

The Four Ways to Respond to a Risk

• Avoid: change the plan so the risk can’t happen. R5 above is an example: book the environment early and the risk goes away.
• Mitigate: lower the chance or the damage. Cross-training for R1 is a good example.
• Transfer: move the risk to someone else, such as a vendor or an insurer. A penalty clause is a common way.
• Accept: do nothing for now, but write down that you chose to. Add a contingency if you can.

How to Build Your Own Risk Register in 6 Steps

1. Gather the team for 30 minutes and ask: “What could stop us hitting the date?”
2. Write each answer as an “If X, then Y” sentence.
3. Score probability and impact together, and agree on the numbers in the room.
4. Pick a response and one clear action for each high and medium risk.
5. Give each risk one named owner.
6. Review the register in every weekly meeting and update the status.

If your risks come from changing scope, read how to manage scope changes without hurting quality. And if a risk could push your finish date, finding the critical path shows you which delays actually matter.

Common Mistakes to Avoid

• Writing vague risks. “Resource issues” tells nobody what to do. “Only one person knows the billing module” does.
• Listing 60 risks. A long list gets ignored. Track the top 10 to 15 that really matter.
• No owner. A risk that belongs to everyone belongs to no one.
• Never reviewing. A register that isn’t updated is just a document.
• Hiding bad news. A high score is information, not blame.

Simple Action Plan

1. Open the free Risk Register Builder.
2. Add the top five risks on your current project.
3. Score them and give each one an owner.
4. Put the register on the agenda of your next weekly meeting.

Conclusion

A risk register is not paperwork. It’s a habit of saying out loud what might go wrong, while you can still do something about it.

Start small. Five risks, five owners, one weekly review. That is already better than most projects manage.

Try It Yourself

Open the Risk Register Builder, enter the six example risks above, and download the result as a PDF. You can find more tools on the Free Tools page.

FAQs

What is a risk register in simple words?

It is a table of things that might go wrong on a project. Each row shows how likely the risk is, how bad it would be, what you will do about it, and who owns it.

What should a risk register include?

At a minimum: a description, probability, impact, a score, a response, an owner and a status. A trigger column is a useful extra, because it tells you when a risk is starting.

How many risks should a risk register have?

There’s no fixed number. Most teams do better tracking the top 10 to 15 risks and reviewing them often, rather than a long list nobody reads.

What is the difference between a risk and an issue?

A risk might happen in the future. An issue is a problem that is happening now. When a risk becomes real, it moves to your issue log.

How often should I update a risk register?

Review it weekly for active projects. Add new risks whenever scope, people, vendors or dates change.

Can I use Excel for a risk register?

Yes. A spreadsheet works well for small projects. Our free Risk Register Builder does the scoring for you and exports a PDF, which saves time.

Related articles

• Stakeholder Analysis Template and Grid (With Example)
• How to Find the Critical Path (With a Simple Example)
• Build Visibility, Influence Decisions and Earn Bigger Opportunities