What Is a Risk Register & How to Create One [Template]

The contents of a risk log will vary based on a number of factors such as client needs, project scale and complexity, and the type of project.

Risk Register Example

Here's what a basic risk register might look like. You can make these as simple or complex as you like, but make sure you're recording all the necessary information that you and your stakeholders will need to make informed decisions.

Common risk scenarios in a website relaunch include delayed approvals, missing redirects, integration failures, and developer unavailability. The table below provides examples of risk scenarios and how a project manager might assess and respond to them.

Example Risk Scenario	Risk Assessment	Response Plan & Owner
R01: Delayed approvals may postpone launch.	Likelihood: High. Impact: High.	Set approval deadlines and assign a backup approver. Owner: Project Manager.
R02: Missing redirects may reduce organic traffic.	Likelihood: Medium. Impact: High.	Map existing URLs and test redirects before launch. Owner: SEO Lead.
R03: Integration failures may disrupt website functionality.	Likelihood: Medium. Impact: High.	Test integrations early and prepare alternatives. Owner: Technical Lead.
R04: Developer unavailability may delay deployment.	Likelihood: Medium. Impact: Medium.	Cross-train team members and document deployment steps. Owner: Development Lead.

Note: These are illustrative assessments. Actual ratings depend on the project's circumstances.

Risk Register Template 

Here is a risk register template with varying levels of complexity (you’ll need to be a member to access the template).

Here's the first level of complexity in the template:

Use the barebones risk register when the majority of the risks are within the control of the project and client team, and have low impact on other areas of the business.

The second level of complexity is the lightweight risk register.

Use this when there are low to mid-level areas of the business that might be impacted and you, your client, and your team have more control of the action plan.

Here's what the most complex level of risk register in the template looks like.

Use this when other areas of the business may be impacted or are responsible for the risk. It involves a high level of reporting on financial impact and severity. The likelihood of these risks may be out of your control, but you need to account for and report on them.

Find more project management templates here.

Why Use a Risk Register?

The purpose of the risk register is to serve as a central place for all potential risks, their impacts, and how you plan to address them.

It helps manage stakeholder and team member expectations around avoiding or mitigating risks and creates a sense of accountability and urgency to address them before they become catastrophic problems that are more difficult to fix down the line.

Note

You might prefer to use a RAID log for tracking risks. These tend to be more comprehensive than risk registers, and include assumptions (or actions), issues, and dependencies (or decisions).

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

What to Include in a Risk Register

For each risk logged in your register, you'll need to include:

• Risk identification number or name: Each specific risk should have a number attached to it that is used consistently in tools and status reports.
• What could go wrong? Provide a description of the risk (e.g. a resource risk like resource capacity issues on the team, which may slow progress and create delays).
• What can we do about it? Detail the mitigation or risk response plan to avoid or lessen the impact of the risk (e.g. create a detailed week-by-week resource plan of when specific resources are needed.
• Risk owner: This is the person responsible for reporting on the impact and likelihood of the risk. They are accountable for solving the risk and notifying you of any changes to the risk.
• Risk impact and probability: Also known as a risk analysis, this is your assessment of how likely it is that the risk event will occur, and what level of impact it will have on your project.
• Risk priority: Based on your risk probability and impact assessments, you'll assign a priority level to each risk and your planned response to it.
• Risk status: Statuses might include open & planning, open & monitoring, closed, and realized.
• Risk category: This is the area of the project that will be impacted or that this issue falls under.

When to Use a Risk Register

I update my risk register throughout the project because risks change as timelines shift, stakeholders weigh in, and new dependencies appear.

• Project Planning: Create the register before work starts so your team can identify risks, assign owners, and plan responses early.
• Project Kickoff: Review risks with stakeholders to confirm priorities, reporting expectations, and mitigation plans.
• Scope Changes: Update the register when timelines, budgets, staffing, or deliverables change and introduce new risks.
• Major Milestones: Revisit unresolved risks before launches, approvals, or key handoffs that could impact delivery.
• Status Meetings: Review active risks regularly so your team stays aligned on priorities and next steps.
• New Blockers: Add risks when issues, delays, or dependencies appear during execution and threaten progress.
• Project Closeout: Close risks once they no longer affect the project or the issue has been resolved.

How to Create a Risk Register

Here are the steps to create a solid and effective project management risk register:

1. Identify Risks

Brainstorm all possible risks that might occur on your project. Here are some questions to ask that might spark ideas:

• Is there a large or small client team? 
• How many levels of decision-makers are there? 
• Is there a board involved that needs continuous reporting on the project or has high-touch involvement in the decision-making process?
• Does this project impact others within the organization?
• Does your client have high attention to detail and want to be in the know about details, or do they trust you and your project team members?
• Is there a high or low level of complexity? 
• Are there a number of business departments involved in the project? 
• Is there a large number of resources involved?
• Is there high attention to data and/or security requirements?

You may not have the expertise to identify all potential risks, so make risk management a team exercise during project planning. Have a separate conversation with your client team and complete the same exercise.

2. Estimate Risks

Conduct a risk assessment to determine how likely each risk is to occur and what impact it might have on your project. It can be helpful to plot this kind of qualitative risk analysis on a risk matrix to visualize relative levels of potential impact and likelihood.

At this stage, you'll also note risk category (e.g. is it a threat to the project schedule, budget, etc.) and priority level according to your impact and likelihood matrix (the risks in the top right are your highest priorities).

Assign a status to each risk as well. If you're still in the planning phase of your project, all risks will be "open" or "planning", but as you progress through the project and risks occur (or don't) update the status to monitoring, closed, and realized (as appropriate).

Hot Tip

Depending on the number of risks in your log, you might categorize them by the phase where they have the highest chance to occur.

3. Create Risk Response Plans

Plan your response to each risk. What will you do if it occurs? What steps can you take to avoid it or mitigate its impact?

There are a variety of risk management strategies you can use, but risk responses generally fall into four major categories of risk response:

• Avoidance: This involves taking concrete steps to eliminate the chance of the risk being realized.
• Transference: This means shifting risk ownership and responsibility elsewhere (e.g. outsourcing data storage and security to a third-party vendor).
• Mitigation: This involves taking steps to reduce the negative impact of the risk. This is used when you can't avoid the risk entirely.
• Acceptance: This means acknowledging the risk but not implementing a contingency plan unless the risk is realized.

When considering responses to each risk, you need to factor in the potential impact of the response itself. Here are some potential knock-on effects to keep in mind:

• Inherent risk: These are the risks that you've identified on the project.
• Residual risk: Risks that remain even after a risk response or controls have been implemented
• Secondary Risk: A new risk that arises from implementing a response to another risk

4. Assign Owners

Assign someone on your team or on the client's team to be responsible for each risk. This is the person that will implement and oversee the planned risk response and monitor the status of the risk throughout the project.

As the project manager, you are responsible for the majority of risk on the project, but it doesn't need to be completely on your shoulders. For example, you might make the client responsible for the backup plan if they aren't able to deliver their website content when they promised (jeopardizing the project timeline).

5. Monitor and Adjust

Keep your risk register updated throughout the project. At a minimum, review it every time you complete a milestone or key deliverable, or every time a risk is realized or successfully avoid.

Store it in a handy place, especially one where the whole team can access it and view it as needed.

How to Maintain Your Risk Register

Creating a risk register is just the beginning. To keep it useful throughout the project, you need to update risk assessments, follow up on response plans, and make sure the team knows when priorities change.

Here's how to maintain your risk register as your project progresses:

1. Set a review schedule: Review the register during regular status meetings and before major project milestones. High-priority risks may need more frequent attention.
2. Reassess existing risks: Check whether each risk's likelihood, impact, or priority has changed. For example, an approaching launch deadline could increase the urgency of delayed client approvals.
3. Follow up with risk owners: Confirm that assigned team members are carrying out their response plans. Update actions, deadlines, and ownership when necessary.
4. Update risk statuses: Add newly identified risks, close those that are no longer relevant, and move risks that have occurred into your issue-management process.
5. Communicate important changes: Highlight emerging risks, overdue actions, and changes in priority so stakeholders can make informed decisions.

A well-maintained risk register should give your team a clear picture of which risks need attention, who's responsible, and what needs to happen next.

Risk Register Best Practices

Here are a few risk register best practices to follow throughout your project.

• Put the risk register in a visible place for all parties to see on a regular basis, such as the project management software or risk management tool you're using.

• Treat risk as you would budget, time, and scope. Review it in your status meetings and in your status reports so all involved are aware of their accountabilities. This also reduces surprises that might halt a project or tarnish a relationship.
• For smaller projects where a complex project risk register is overkill, create an item in your project management tool and add risks as sub-items for a lightweight way to track them. You can write comments about solutions or changing levels of severity or priority in a cleaner way than an Excel spreadsheet.

Common Risk Register Pitfalls and Limitations

Risk registers help project managers anticipate problems, but they have limitations. They can't predict every risk, and simply documenting a potential problem doesn't guarantee it will be prevented.

Here are some common pitfalls and how to overcome them:

• Tracking too many low-priority risks: An overloaded register can make critical threats harder to identify. Focus on risks with the greatest potential impact and prioritize them accordingly.
• Relying on subjective assessments: Likelihood and impact ratings often depend on individual judgment. Use consistent scoring criteria and involve relevant stakeholders to make assessments more reliable.
• Identifying risks without taking action: A list of potential problems won't protect your project. Assign risk owners, define response plans, and establish clear responsibilities.
• Overlooking unexpected risks: No register can capture every possible scenario. Encourage ongoing risk identification and maintain contingency plans for unexpected disruptions.

When Might a Risk Register Be Unnecessary?

Not every project needs a detailed, standalone risk register. For small, low-complexity projects with limited dependencies, a simple risk tracker or checklist within your project management software may be sufficient.

Risk registers also shouldn't replace issue logs, contingency planning, or regular communication. They're most effective when used as part of a broader risk management process that helps teams respond to uncertainty rather than simply document it.

What's Next?

Want to connect with other digital project managers to share resources and best practices? Join our membership community and get access to 100+ templates, samples, and examples and connect with 100s of other digital project managers in Slack.