What is a risk register?

A risk register is a living list of everything that could derail a program, captured in one place. Each entry names the risk, a category, how likely it is, how bad the impact would be, a single owner, and the planned mitigation. It turns vague worry into a tracked list you can review, assign, and close.

How do you calculate a risk score?

Multiply likelihood by impact. Most teams rate each on a 1 to 5 scale, so the score runs from 1 to 25. A risk that is very likely (5) and very damaging (5) scores 25 and goes to the top. A low-likelihood, low-impact risk scores 1 to 4 and can usually be monitored rather than actively worked. Color coding the score helps the eye go straight to what matters.

What is the difference between likelihood and impact?

Likelihood is the probability that the risk actually happens. Impact is how much damage it does if it does happen. They are independent. A data center fire is high impact but low likelihood. A late design review is moderate on both. Scoring them separately keeps you from treating a rare catastrophe and a frequent annoyance the same way.

How often should you update a risk register?

Review it on the same cadence as your program status, usually weekly or biweekly. Re-score risks as conditions change, close the ones that no longer apply, and add new ones the moment they surface. A register that is updated once and forgotten is worse than none, because it gives false confidence that risk is being managed.

Program Risk Register

Track every risk that could derail your program in one place. Score each by likelihood and impact, assign an owner and a mitigation, then export to CSV or print. Everything saves in your browser. No signup.

Auto-sort by score (highest first)

Risk	Category	Likelihood	Impact	Score	Owner	Mitigation	Status

1-6 Low - monitor 7-12 Medium - actively manage 13-25 High - mitigate or escalate now

How to use a risk register

A risk register is the difference between managing risk and hoping for the best. You list everything that could go wrong, score each one, give it a single owner, and write down what you are doing about it. The act of writing a risk down forces you to decide whether it is real and who is on the hook for it.

Score is just likelihood times impact. Rate each on a 1 to 5 scale and the product tells you where to spend attention. A risk that is both likely and damaging scores high and gets worked this week. A rare, low-damage risk scores low and gets a glance at review. The color coding exists so an executive can scan the register in ten seconds and see where the program is exposed.

Common mistakes to avoid

No owner, or a team as the owner. A risk owned by everyone is owned by no one. Name one person.
Confusing likelihood and impact. A data center fire is high impact but low likelihood. Score them separately or you will overreact to rare events and ignore frequent ones.
Writing mitigations you never do. A mitigation is a commitment, not a wish. If no one is acting on it, the risk is still live.
Building it once and never updating it. Re-score at every status review, close what no longer applies, and add new risks the moment they surface.
Treating the register as a place to hide bad news. The point is to surface exposure early so it can be managed, not to bury it in a spreadsheet.

For more on running programs across many teams, see the Insights notes on dependency management, decision logs, and escalation paths.

Built by Arsenii Samoilov, a Senior Technical Program Manager with 19+ years at Intuit, Atlassian, Adobe, Salesforce, Roku, and Apple. If your team needs help standing up program governance, get in touch.

Read the Insights →