Risk Register: What It Is and How to Build One (Template)

A risk register is the document that turns vague project anxiety into a structured, manageable list. Every project has risks. The question is whether those risks live in someone's head or in a shared document the whole team can act on.

What is a risk register?

A risk register is a project management tool that records identified risks, their probability and impact scores, assigned owners, and planned response strategies in a single shared document. It's sometimes called a risk log, though the two terms are essentially interchangeable in practice.

The register doesn't eliminate risk. It makes risk visible, so your team can decide which risks to mitigate, which to monitor, and which to simply accept. A risk you've documented is a risk you can manage. A risk that lives only in someone's memory is a deadline waiting to blow up.

Key Facts

• Projects with active risk management practices are 2.5 times more likely to meet their goals than those without them (PMI Pulse of the Profession, 2023).
• Poor risk management is the second most common cause of project failure, cited by 39% of project professionals globally (PMI, 2024).
• Organizations that manage risks proactively waste 13 times less money than those that don't (PMI Pulse of the Profession, 2023).

What goes in a risk register (the columns)

A risk register works best when every column has a clear purpose. Here are the standard fields and what each one does.

Here's what a populated risk register looks like with a few realistic rows:

The Risk Score column is your prioritization engine. Risks scored at 6 or higher typically land on your weekly agenda. Risks scored at 3 or below can move to a watch list unless something changes.

Risk register vs risk log vs RAID log

These terms overlap more than they should, which creates real confusion in project teams. Here's a clear comparison.

In practice, "risk register" and "risk log" are used interchangeably in most teams. The meaningful distinction is between a standalone risk register (risks only, with full depth) and a RAID log, which covers risks alongside assumptions, issues, and dependencies in a single document at moderate depth.

For most project managers, the RAID log is the right starting point. The risk register makes sense when your project is large enough, or regulated enough, that the risk category alone needs its own dedicated document with full probability-impact analysis.

Benefits of a risk register

It surfaces risks before they become crises. The process of building a risk register forces the team to think through what could go wrong before anything actually does. Teams that run through this exercise at project kickoff catch problems weeks or months earlier than teams that don't.

It creates a shared language for uncertainty. When everyone on the team can point to the same risk register, "I'm worried about the vendor timeline" becomes "R-001 is rated High/High and Alex owns the mitigation." That precision changes how conversations go in status meetings.

It gives the project manager something to show. When a sponsor asks why a delivery date slipped, the risk register shows whether the event was logged, who owned it, and whether the mitigation plan was followed. That's not just defensive. It's how project teams build credibility over time.

It connects risk to the work breakdown structure. Once risks are documented, you can trace which workstreams carry the most exposure. That informs how you allocate buffer in your schedule and where you assign your strongest people.

It feeds better stakeholder analysis. Knowing which risks affect which stakeholders helps you decide who needs to be informed, who needs to be consulted, and who has the authority to approve a response plan.

Common mistakes

Logging risks once and never reviewing them. A risk register that isn't reviewed regularly becomes fiction. Risks change status. New risks emerge. Owners leave. Schedule a fixed slot in your weekly status meeting for a 10-minute risk review, or the document will drift.

Using vague descriptions. "Communication risk" is not a risk. "Client stakeholders have not confirmed sign-off on the scope document, and the project can't move to the build phase without it" is a risk. Be specific enough that someone who wasn't in the room when the risk was logged understands exactly what's at stake.

Assigning risks to teams instead of people. "The IT team" is not an owner. One named person is the owner. That person monitors the risk, escalates if needed, and updates the status at each review. A team can't be held accountable. A person can.

Rating everything as High. When every risk is a 9, nothing is a 9. Calibrate your scores honestly. A well-rated register lets you focus energy on the risks that actually matter. A register full of 9s creates noise and burns attention on things that don't warrant it.

Treating the register as a compliance artifact. Some project managers build a risk register because the project governance framework requires one, then never open it again. A risk register only earns its keep if it's a live document in active use.

Forgetting to close resolved risks. When a risk is mitigated or avoided, close it with a note on what happened. Those closed entries become institutional knowledge for the next similar project.

How to build a risk register

Step 1: Identify the risks

Start at project kickoff. Run a structured brainstorm with your core team: what could go wrong? What are we assuming that might not hold? What are we depending on from external teams or vendors? Pull in lessons-learned documents from similar past projects. The goal is to surface as many risks as possible before you start ranking them. Quantity before quality at this stage.

Common categories to prompt the discussion: technical risks, resource risks, schedule risks, budget risks, external dependencies, compliance and regulatory risks, and stakeholder risks.

Step 2: Write clear, specific descriptions

For each risk, write a one-to-two sentence description that explains what the risk is and why it matters to the project. Avoid shorthand. "API integration failure" is less useful than "Third-party payment API may not support our authentication protocol, requiring a custom middleware build that adds four to six weeks to the schedule."

Step 3: Score probability and impact

Use a consistent scale across the whole register. A 3-point scale (Low, Medium, High mapped to 1, 2, 3) works for most teams. A 5-point scale works for large programs. Don't mix scales within the same register.

Score probability based on how likely the risk is to occur given everything you know about the project context, the team, the vendor history, and the market. Score impact based on how bad the outcome would be if the risk materialized. Then multiply: a Medium probability (2) combined with High impact (3) gives a score of 6.

Step 4: Prioritize by score and assign owners

Sort your risk register by score, highest to lowest. Risks at 6 or above get active mitigation plans and weekly review. Risks at 3 to 4 go on the watch list and get reviewed monthly. Risks at 1 to 2 are accepted: you note them but don't allocate mitigation resources.

For every risk at 4 or above, assign a named owner. That person is responsible for monitoring the risk, executing the response plan, and flagging any change in status. Cross-reference with your RACI matrix to make sure the owner assignment is consistent with project accountability roles.

Step 5: Define response strategies

Each risk needs a documented response. There are four standard types:

• Avoid: Change the project plan to eliminate the risk entirely. Example: if a vendor has a poor track record, switch vendors before the risk can materialize.
• Mitigate: Take action to reduce the probability or impact. Example: cross-train a second developer to reduce the impact of a key-person risk.
• Transfer: Shift the risk to a third party. Example: purchase project insurance or add a performance clause to a vendor contract.
• Accept: Acknowledge the risk and prepare a contingency plan, but don't take proactive action. Best for low-score risks where mitigation costs more than the potential impact.

Step 6: Review and monitor throughout the project

The risk register is not a kickoff artifact. It's a living document. Review it weekly in your status meeting: update statuses, confirm response plans are being executed, close resolved risks, and add new ones as they emerge. During high-risk phases of the project life cycle, consider a mid-week risk check for any High-rated open items.

When a risk materializes, it becomes an issue and should be tracked accordingly. In a RAID log, you'd move it from the Risk section to the Issue section. In a standalone risk register, change the status to "Realized" and open a separate issue log entry.

Risk register examples by project type

Different project types carry different risk profiles. Here's how a risk register entry looks across three common contexts.

For a software project, technical and resource risks tend to dominate. For construction, regulatory compliance and weather-related schedule risks carry the most weight. For marketing launches, vendor and creative delivery timelines are the biggest exposure. The structure of the register stays the same across all three. The categories and scores just shift.

If your project involves multiple workstreams, consider linking your risk register to the critical path method analysis. Risks that affect critical path tasks deserve higher priority than risks that affect float tasks, even at the same probability-impact score.

Best practices

Do assign one named owner per risk. Not a team. Not a role. A person.

Do review the register in every status meeting. Even a 10-minute pass is enough to keep it current and credible.

Do connect high-scoring risks to your project scope statement. If a risk threatens core deliverables, that's a sponsor conversation, not just a PM note.

Do close risks with a written note. When a risk is resolved or avoided, document what happened. Future teams on similar projects will use those closed entries.

Don't let the register grow without pruning. A register with 80 open risks is unusable. Close accepted risks, archive resolved ones, and keep the active list focused on what the team can actually act on.

Don't use color alone to signal severity. Some team members are color-blind, and exports often lose formatting. Use text labels (Low, Medium, High) alongside any color coding so the information survives format changes.

Frequently asked questions

What is the difference between a risk register and a risk assessment?

A risk assessment is the process of identifying and evaluating risks. A risk register is the output document that records the results of that assessment, plus ongoing tracking over time. You do a risk assessment to populate the register. Then you maintain the register throughout the project to monitor whether the risk landscape changes.

How often should you update a risk register?

At minimum, once a week in the regular project status meeting. High-severity open risks often need more frequent check-ins, especially during project phases where those risks are most likely to materialize. Add new risks whenever a change request, a new dependency, or an unexpected event introduces uncertainty the team wasn't tracking before.

Who owns the risk register?

The project manager owns the register as a document and is responsible for keeping it current. But each individual risk has its own named owner, the person accountable for monitoring and responding to that specific risk. This distinction matters: the PM shouldn't be the default owner for every risk. The person closest to the risk, whether that's a technical lead, a finance analyst, or a procurement manager, is usually the right owner.

What is the difference between a risk register and an issue log?

Timing. A risk register tracks events that haven't happened yet. An issue log tracks problems that are already occurring. When a risk materializes, it graduates from the risk register to the issue log. Some teams combine both into a single document, which works fine as long as the status clearly distinguishes between prospective risks and active issues.

Does every project need a risk register?

Not always in a formal sense. A two-week internal project with a small team can get by with a shared note or a quick risk conversation at kickoff. But any project with multiple stakeholders, external dependencies, a budget over a certain threshold, or regulatory implications should have a formal risk register. The project charter is a good place to decide: if the project is complex enough to need a charter, it's complex enough to need a risk register.

---

The best risk registers are simple enough to actually use and detailed enough to actually matter. Start with the nine columns above, score your risks honestly, assign real owners, and review the document every week. Do that consistently, and the register becomes one of the most valuable conversations your team has throughout the project.

Related reading

• RAID Log: Risks, Assumptions, Issues, and Dependencies
• Project Charter: Define Scope and Get Stakeholder Buy-in
• Work Breakdown Structure: How to Build One
• RACI Matrix: Clarify Roles on Any Project
• Stakeholder Analysis Matrix
• Triple Constraint in Project Management