A Risk Register is a document that lists the identified risks on your project, the results of their analysis (probability, impact, effects), the risk owners, and the response plans. You use it to monitor and control risks for the whole project life cycle.
Most project managers agree the Risk Register is one of the most important documents in project management. Few keep it in good shape. They overcomplicate it, the team stops opening it, and you end up putting out fires you could have seen coming.
For me, the first steps in risk management were overwhelming too, and the Risk Register was the hardest part. When I got my PMP, I tried to bring its processes to a company that had none. Nobody followed them, and I was back to managing chaos.
If you’ve tried to manage risks by the book, you may know that feeling.
At first glance, the Risk Register looks simple: you fill in what you know about each risk and move on. Many junior project managers fall into that trap.
A Risk Register is a living thing:
- The information in it changes fast.
- Risks evolve and change their attributes.
- A Risk Response Plan may not work as well as you expected.
- Threats and opportunities disappear or become irrelevant.
Before you add a single column, remember this:
A Risk Register should be simple, adaptable, maintainable, and close at hand.
You want just enough process to stay in control, light enough that your team follows it.
Risk Register Example Video
Watch the video for more examples and illustrations. I walk through more risks there than I could fit in this article.
Simple Risk Register Example
The table shows the register from the image above as text, so you can read it on any screen. I left out the WBS Element, Category, and Expected Effect Date columns to keep it readable. You’ll find them in the image.
| Index | Risk | Effects | Probability × Impact = Rank | Owner | Response Plan |
|---|---|---|---|---|---|
| 0001 | The web component of the application depends on the design created by the external design team. | Delays in the design delivery will impact the project schedule. | 6 × 10 = 60 | D. Nizhebetskyi | The procurement manager should include these terms in the contract: – Weekly reports. – Weekly on-site meetings. – Delivery via a collaboration system (e.g., InVision). |
| 0002 | Resources for mobile development are limited and in high demand. | – Unavailable developers may cause delays. – Quality may suffer due to multitasking. | 8 × 8 = 64 | D. Nizhebetskyi | – Develop a cross-project HR plan together with Ann Smith and Ron Nagle. – Secure the required resources. |
| 0003 | New functionality may require changes to the infrastructure. | – Poor performance. – The client won’t accept the delivery. | 3 × 10 = 30 | R. Anderson | – Reserve 2 days of work at the beginning of January for the Infrastructure Team. – Run performance tests on a regular basis. – Reserve time for performance optimization (about 2 weeks). |
| 0004 | Implementation depends on Deliverable 1.1.3. | Implementing the UI will take more effort. | 3 × 7 = 21 | J. Robertson | – Task PT-332 adds the Risk Reserves. – The BSA should control the vendor on a regular basis. – Final designs should not require any unsupported technologies. |
| 0005 | Only one engineer in the company has the skills to deliver the work package. He is in conflict with the functional manager, and there is a good chance he will leave the company. | Delivery will be fully blocked. | 6 × 10 = 60 | A. Lee E. Remington | – Ask the HR department to open a new vacancy. – Ask HR to find outsourcing or freelancing options. – Start knowledge transfer ASAP. |
These are the columns I suggest you include, and how to fill in each one.
Risk Index
A unique number that identifies a risk.
Over the life of a project, you’ll log dozens of risks, sometimes hundreds. Even on a small project! You need a fast way to find and point to the right risk in the Register.
Four-digit numbers work in most cases. Start with 0001.
Don’t overcomplicate it. Add one to the number with each new risk, and never decrease it.
WBS Element
I suggest you connect the Risk Register to the rest of your project documentation.
The Work Breakdown Structure is the hub that ties all the knowledge areas together.
If you link a risk to the top-level item, it threatens the outcome of the whole project.
If you link it to a Deliverable or a Work Package, it’s an isolated risk. Later, check whether that work package is on the Critical Path.
Modern project management software can log risks against a WBS element, so you don’t need a separate spreadsheet.
Risk Category
Grouping risks by category helps you fight the root cause of problems. It may show you a way to handle several risks with one Risk Response Plan.
Decide which categories to use before you start logging risks. For example:
The common ones: scope, schedule, cost, quality, and HR.
Industry-specific ones (e.g., IT): requirements, design, implementation, testing, and deployment.
PESTLE: political, economic, social, technological, legal, and environmental.
Pick the categories that fit your project. To broaden your view of possible risks, read this article:
43 Risk Categories: Complete List of Categories of Risks
Risk Title
A one-sentence description of the risk. Write it so it shows both the nature and the severity of the risk.
Compare these three:
“David may leave the company, which may impact the deadline.”
“David will most likely leave the company, which will impact the deadline.”
“David leaves the company on June 16, which will impact the deadline.”
On small and medium projects, the risk title may be the only description you need.
Risk Description (Optional)
Add a Risk Description for two reasons:
- Your risks are complex and affect several areas in different ways.
- You share the Risk Register with stakeholders as is, and they need more context about each risk.
Above all, anyone who reads the Risk Register should understand the risks in it.
Effects
A narrative description of the potential impact on the project.
You won’t find this column on most templates. Add it anyway.
Your stakeholders, clients included, may not know risk management terms and concepts. And Impact and Probability expressed as numbers don’t tell them much.
For example:
You want approval to add $10,000 to the project budget as a Risk Reserve for a deliverable.
Will you get it because Risk #0023 has impact 7 and probability 6?
I doubt it!
Write the effects the way you’d describe the risk in person. Two or three sentences are enough.
PRO TIP: Copy and paste these descriptions into your updates to stakeholders.
Probability
The likelihood that the risk will happen.
This value comes from Qualitative Risk Analysis. Use a 1 to 10 scale, or Low, Medium, and High.
Impact
The severity of the effect on the project.
It also comes from Qualitative Risk Analysis. Use the same scale as for Probability.
Agree on what each number means before you score anything. An impact of 7 tells your sponsor nothing until your team agrees on how much money or time a 7 costs.
Risk Rank
I use this value to sort risks by severity.
To get the Risk Rank, multiply Probability by Impact:
Risk Rank = Probability × Impact
On a 1 to 10 scale, you’ll get values from 1 to 100.
The Risk Rank is the easiest way to shortlist the risks you’ll work on first. You can also use the Impact/Probability matrix and mark the risks for further analysis.
Quantitative Analysis Values (Optional)
Don’t overload the Risk Register with information you won’t use.
If you don’t perform Quantitative Risk Analysis, skip these columns. Even if you do, you’ll run it only for the top-priority risks.
That’s why you may prefer to keep Quantitative Analysis in a separate document. It’s up to you.
Risk Owner
The name of the person responsible for the risk.
This person monitors and manages the risk and reports on it to you.
Don’t put your name on risks that have nothing to do with project management. Subject matter experts should own the technical risks.
Response Plan
The action plan to avoid or mitigate the risk.
You can also state here that you accept the risk and won’t do anything about it.
To learn more about Risk Response Plans, read this article:
Risk Response Strategies (Definitive Guide with Examples)
How to Use a Risk Register on a Real Project
Use these ten rules to keep your Risk Register useful on a real, messy project.
1. Keep It Close at Hand
Books say you start filling in the Register during Risk Identification. On real projects, start the day you join.
Start filling in the Risk Register as soon as you’re assigned to the project.
A good project manager is always in risk identification mode. Log risks as early as project initiation, or even in the pre-sales phase.
2. Treat It as a Permanent Draft
It’s OK to log your thoughts, concerns, and high-level risks. You’ll refine them later.
As you get more information from subject matter experts, update your entries.
Then review the Risk Register with stakeholders. You want their feedback, and you need to keep them informed about the changes.
3. Don’t Mix Identification and Analysis
Write down a new risk now. Come back to analyze it later.
You don’t need to fill in all the columns at once. Write down Risk Titles during meetings and calls.
Find time to add the details later, and do it with your team members whenever you can.
4. Add Only the Detail You Need
Are you the only person who uses the Risk Register? Then you don’t need all the columns I described above.
Be selective with your effort.
Risk management isn’t free. It costs your time, and more often than not, it needs your team’s input too.
5. Don’t Do It Alone
At some point, start delegating risks to your project team and stakeholders.
Each risk needs a responsible person.
You’re the expert in project and risk management. You don’t have to know every knowledge area behind each risk.
Some experts will analyze a risk better than you can and suggest a better action plan.
6. Share It With the Team
Keep your team involved in risk management.
The catch:
You need to teach them your risk management approach.
Don’t assume they know what you know. You’ll repeat the same information about risk management many times.
Skip that step, and you’ll end up with a Register that only you read.
7. Refine It Before You Finalize the Project Management Plan
Put most of your effort into refining and analyzing the Risk Register before you finalize the project management plan.
By that point in planning, you have the scope baseline and drafts of the budget and the schedule.
You’ll also have quality standards, an HR plan, drafts of the procurement documents, and so on.
You put it all together in the first draft of the project management plan. Then you do the bulk of the risk analysis and define the responses.
8. Put Reviews on Your Calendar
Open the Risk Register at these moments:
- Your review sessions. Set them up as a recurring calendar event.
- A new change request.
- The start and the finish of work on a deliverable.
- A risk that happens.
- A Risk Response Plan that doesn’t work.
- A risk response that works.
You get the point. Open it often!
9. Keep It Up to Date
Risk management doesn’t end with planning.
Risks change their impact and priority over time because of other risks, change requests, and external factors.
Monitor your risks for the whole project life cycle.
10. Make It Presentable
Risk management pays off when you can communicate future risks to stakeholders in a way they understand.
You manage their expectations, keep them engaged, and prepare them for problems.
Make the information in your Risk Register easy to share.
Where the Risk Register Fits in Risk Management
In this video, I give you an overview of all the Risk Management processes in the PMBOK® Guide.
PMBOK Definition of Risk Register
The PMBOK® Guide puts it this way:
“Risk Register (or Risk Log) is a document that contains all the results of risk analysis and where risk response plans are recorded.”
The results of the other risk management processes end up in the Risk Register too.
The book says you fill it in during the planning phase. On real projects, start earlier, as I explained in rule #1.
A good practice is to share the Register and your lessons learned about risks as part of the project archive. You add to your organization’s knowledge base and give your future projects a head start.
Risk Register Template: Why the File Is the Easy Part
If you came here for a template, I get it. You want something you can fill in today.
A template helps. It gives you the columns. You’ve already seen all of them above, and you can set them up in a spreadsheet or your project management tool in ten minutes.
But you can have a perfect template and still spend your days putting out fires if nobody on your team opens the file after kickoff.
Control comes from the process behind the file: how you identify risks, score them, assign owners, and review them as the project changes. Once you understand that process, the document is the easy part.
And today, AI builds the document better than any template. You give it the context, and you get a first draft of your Risk Register in minutes, with your vendors and your deadlines in it.
Context is the catch. Type “create a risk register for my project” into ChatGPT, and you’ll get a generic list of risks that could belong to anyone’s project.
I put together a free AI Prompt Pack for project managers to solve that: 27 copy-paste prompts for real IT project work. Two of them fit this article:
- Project Context File Builder. You build one file with your project goal, stakeholders, scope, team, timeline, and known risks. Then you attach it to every prompt, so AI answers with your project’s details.
- Impact and Probability Grades Descriptor. AI asks you a few questions about your project and builds a 5-point scale for your Probability and Impact columns. A 7 then means the same thing to your team and your sponsor.
Get the free AI Prompt Pack and run these two prompts on the project you’re managing now. You’ll have a first draft of your Risk Register before your next status meeting.
Risk Register FAQ
What does a risk register look like?
It’s a table with one row per risk. The columns hold the risk index, category, description, effects, probability, impact, risk rank, owner, and response plan. You can see a real one in the example above.
What should a risk register include?
Start with an index, a risk title, probability, impact, risk rank, owner, and a response plan. I also add an Effects column, because stakeholders understand a short story better than numbers. Add the WBS element, category, and a longer description when your project needs them.
How do you create a risk register?
Set up the columns in a spreadsheet or your project management tool. Log risks as soon as you hear about them, even in pre-sales. Score probability and impact, sort by risk rank, give each risk an owner, and agree on a response plan. Then review the register on a schedule and whenever the project changes.
Is a risk register the same as a risk log?
Yes. The PMBOK® Guide uses both names for the same document. Don’t confuse it with an issue log: a risk register tracks what might happen, and an issue log tracks problems that have already happened.
If you track risks, assumptions, issues, and dependencies in one place, you’re using a RAID Log. In this video, I explain how it works and when it’s a better choice than a Risk Register.
Who owns the risk register?
The project manager owns the register and keeps it up to date. Each risk in it has its own owner: the person with the right expertise, who monitors that risk and reports on it to you.
How often should you review a risk register?
Put a recurring review on your calendar. Also open the register when a change request comes in, when you start or finish a deliverable, and when a risk happens.
Conclusion
A Risk Register is a simple document. It’s also one you’ll update until the last day of your project.
Keep it simple, adaptable, maintainable, and close at hand. Share it with your team so they follow it. Use it to make better decisions on response plans, focus on the most severe risks, and spend your risk management budget where it counts.
Do that, and your project runs on a system, not on overtime. That’s how you stop managing chaos and start managing projects.
Before you start your next Risk Register, grab the free AI Prompt Pack and build your Project Context File first. You’ll get answers about your project instead of generic risks.