Example of a Risk Register

This blog post walks you through an example of a risk register, according to PMBOK guidelines.

Explanation of the above Example of a Risk Register

A solid risk register, based on the PMBOK® Guide, is your go-to tool to manage all those "what ifs" that keep project managers up at night. Below, we’ll walk through some of the key components of a risk register, what they mean, and why they matter—with a tone that’s more coffee chat than textbook.

1. 📈 Probability – How Likely Is It?

Probability is just a fancy way of asking, “How likely is this thing to actually happen?”

In most risk registers, we rate this as High, Medium, or Low. Some organizations get more precise and use percentages or a scale from 1 to 5. But at the core, it’s about estimating the chance a particular risk event will occur.

For example:

• A vendor delay? If that’s happened before, you might call that High probability.

• A meteor strike on your data center? Probably Low (hopefully).

It’s subjective, yes—but the key is consistency. Use a scale your team understands and agrees on.

2. 💥 Impact – How Bad Would It Be?

Next up is Impact, which answers the question: “If this risk actually happened, how much would it mess up the project?”

This could mean delays, budget overruns, scope changes, loss of data, or all of the above. Like probability, impact is usually rated as High, Medium, or Low—but again, some teams prefer numbers (e.g. 1–5).

A High-impact risk might derail your timeline by months, or cause serious financial damage. A Low-impact risk might just mean a few hours of rework.

It’s worth noting that even a low-probability risk with high impact should still be on your radar.

3. 🎯 Risk Score – Combining Probability and Impact

Once you know the probability and impact, you can combine them to calculate a risk score. This helps you rank risks so you know which ones need immediate attention and which ones can go on the watchlist.

The formula is simple:

Risk Score = Probability × Impact

Let’s say you use a scale of 1 to 3. If a risk has a Probability of 3 (High) and an Impact of 2 (Medium), then the Risk Score is 6. This gives you a quick, comparable way to prioritize.

A visual risk matrix often helps here—those colorful grids that show which risks are low (green), medium (yellow), or high (red). Super helpful in meetings when you need to make decisions fast.

4. 🛡️ Response Strategies – What’s the Game Plan?

Once you’ve identified a risk and scored it, the next step is deciding how to handle it. PMBOK gives us a menu of risk response strategies, and you pick the one that fits best.

Here are the usual suspects (for negative risks, aka threats):

• Avoid – Change the plan so the risk can’t happen at all. (E.g. not using a risky vendor.)

• Mitigate – Reduce the chance it’ll happen or lessen its impact. (E.g. more testing, backup plans.)

• Transfer – Push the risk to someone else. (E.g. hire a subcontractor or buy insurance.)

• Accept – Acknowledge the risk and live with it. (Sometimes doing nothing is a valid strategy.)

For positive risks (opportunities), you’ve got similar but opposite strategies: Exploit, Enhance, Share, and Accept. But most registers focus more on threats, since they’re often more urgent to handle.

5. 🛠️ Mitigation & Contingency Plans – Being Proactive and Reactive

So you’ve picked your strategy. Now what? That’s where mitigation and contingency plans come in.

• Mitigation Plans are what you do before the risk happens, to try to prevent it or soften the blow. Think of it as preventive care.

• Contingency Plans are your “Plan B” for when the risk actually materializes. This is your emergency response.

For example: Say your risk is “data corruption during system migration.”

• Mitigation Plan: Run multiple pre-migration tests and back up all data.

• Contingency Plan: Restore from the backup and roll back to the previous version.

The goal is to avoid scrambling in the middle of a crisis. If you’ve got these plans ready, you’re already ahead of 90% of teams.

6. 👤 Risk Owner – Who’s in Charge?

Every risk needs a Risk Owner—someone who’s responsible for monitoring the risk, managing it, and executing the plan if needed. This shouldn’t just default to the project manager every time (even if that’s tempting).

Pick someone with the right knowledge and authority. If it’s a technical risk, maybe the IT lead owns it. If it’s about a vendor contract, maybe your procurement manager is the right person.

Clear ownership = accountability = faster action when something goes sideways.

✅ Final Thoughts

A risk register isn’t just a checkbox in your PM software—it’s your early warning system. When used well, it keeps you and your team proactive instead of reactive. It helps avoid surprises, makes decision-making easier, and builds trust with stakeholders who appreciate that you've got your eyes on the road ahead.

So, the next time someone rolls their eyes at “risk management,” just smile. You’ll be the one with a backup plan when the unexpected hits.