A risk register is the most-used artifact in project risk management and the most-abandoned. Teams set one up at kickoff with twelve neatly labeled columns, fill it in once, and never open it again. The register that actually protects a project is smaller, updated on a cadence, and owned by named people. This guide covers what to put in each column, the risk categories worth tracking, how to build a register you will maintain, and a worked example you can copy.
Key takeaways
- A risk register is a living document that records each identified risk, its likelihood and impact, a score, an owner, and a planned response.
- The core columns are risk ID, description, category, likelihood, impact, score, owner, response, and status. Add trigger, due date, and contingency only if you will maintain them.
- An accurate five-column register that is reviewed every cycle beats an abandoned twelve-column one.
- The register is the record; the risk management plan is the method that governs it, and the issue log is where a risk goes once it has actually happened.
What is a project risk register?
A project risk register is a living document that lists every identified risk on a project, scores each one for likelihood and impact, assigns an owner, and records the planned response. It is the single place where risk information lives, so the team, the sponsor, and the PMO all read the same picture. The register is not a one-time deliverable; its value comes from being updated as risks change, close out, or new ones appear.
The register works the same way at the portfolio level, where it aggregates the exposures that cut across projects. The discipline of managing those combined risks is project portfolio risk management, and the portfolio register is one of its main tools. At either level, the register only earns its keep if it is reviewed on a set cadence rather than filed after kickoff.
What to include: the standard risk register columns
Start with the core columns every register needs, then add the optional ones only if you will actually keep them current. The point is a register that gets read, not one that looks complete.
| Column | What it holds | Core or optional |
|---|---|---|
| Risk ID | A unique reference (R-01, R-02) so the risk can be cited in reports | Core |
| Description | The risk stated as a cause and effect: if X happens, then Y | Core |
| Category | The area most affected: schedule, budget, technical, external, resource | Core |
| Likelihood | Probability the risk occurs, on a consistent scale (1 to 5) | Core |
| Impact | Severity if it occurs, on the same scale (1 to 5) | Core |
| Risk score | Likelihood multiplied by impact, used to rank the register | Core |
| Owner | The one person accountable for the response, not a team | Core |
| Response | Avoid, mitigate, transfer, or accept, plus the specific action | Core |
| Status | Open, in progress, closed, or occurred | Core |
| Trigger | The early signal that the risk is about to materialize | Optional |
| Due date | When the response action should be complete | Optional |
| Contingency | The fallback plan if the risk happens anyway | Optional |
The two columns people skip and later regret are owner and trigger. A risk with no named owner belongs to nobody and gets no action. A risk with no trigger gets noticed only after it has already hit, which defeats the purpose of writing it down in the first place.
Risk categories worth tracking
Categorizing risks helps a review team look in the right places instead of staring at a flat list. Most projects draw from the same handful of categories.
| Category | Typical risks |
|---|---|
| Schedule | Slippage, unrealistic estimates, dependency delays |
| Budget / cost | Overruns, scope creep, committed spend that has not hit the ledger yet |
| Technical | Unproven technology, integration failures, performance gaps |
| Resource | Key-person dependency, a scarce skill needed by several projects |
| External | Vendor failure, regulatory change, market shifts |
| Scope / requirements | Unclear or changing requirements, gold-plating |
Budget risk is worth a closer look because it often hides in commitments rather than actuals. Money you have promised to a vendor through a purchase order is already spent from a risk point of view, even though it has not appeared in the accounts, so teams that keep committed spend visible against budget catch an overrun forming weeks before it lands. Resource risk is the other quiet one: a key-person dependency looks minor on one project and severe once you notice the same specialist is a single point of failure across several, which is why it surfaces so clearly in a portfolio-level register.
How to build a risk register
Building one is a short, repeatable sequence. The work is less in the setup than in keeping it alive afterward.
| Step | What you do |
|---|---|
| 1. Identify | Run a risk identification session with the team; capture each risk as cause and effect |
| 2. Assess | Score likelihood and impact on a consistent scale; calculate the risk score |
| 3. Prioritize | Sort by score; decide which risks are worth an active response now |
| 4. Plan responses | Choose avoid, mitigate, transfer, or accept for each top risk; assign an owner |
| 5. Review | Revisit the register on a set cadence; update scores, close what is gone, add what is new |
Step five is the one that separates a real register from a checkbox. Put it on a regular agenda, ideally the same forum where delivery and spend are reviewed, so risk is discussed next to everything else rather than in a meeting nobody attends. At portfolio level that home is the portfolio review meeting, and the top risks should surface in PMO reporting so leaders see exposure alongside status and cost.
Risk register example
Here is a short worked example for a software delivery project, showing how the columns come together on real rows.
| ID | Risk | Category | L | I | Score | Owner | Response |
|---|---|---|---|---|---|---|---|
| R-01 | Lead engineer is shared with two other projects and may be pulled | Resource | 4 | 5 | 20 | Delivery lead | Mitigate: cross-train a second engineer |
| R-02 | Payment vendor API is unproven at our transaction volume | Technical | 3 | 4 | 12 | Tech lead | Mitigate: load-test in a pilot before launch |
| R-03 | Data-migration scope is not yet agreed with the business | Scope | 4 | 3 | 12 | Business analyst | Avoid: freeze scope before build starts |
| R-04 | New regulation may change reporting requirements mid-build | External | 2 | 4 | 8 | Sponsor | Accept and monitor: assign a trigger to watch |
Notice that the register is already ranked by score, so R-01 gets attention first. Notice too that not every risk gets an active mitigation: R-04 is knowingly accepted with a trigger to watch, which is a legitimate response, not a gap. Many of these risks trace back to how projects connect, so a register pairs naturally with solid project dependency management to catch the risks that live in the links between projects.
Frequently asked questions
What is a project risk register?
A project risk register is a living document that records every identified risk on a project, along with its likelihood, impact, a calculated score, an owner, and a planned response. It gives the team and stakeholders one shared view of the risks and their status. Its value comes from being updated regularly as risks change, close, or emerge, not from being filled in once at kickoff.
What should be included in a risk register?
At a minimum, include a risk ID, a description, a category, likelihood and impact ratings, a risk score, an owner, a response, and a status. Optional columns such as a trigger, a due date, and a contingency plan add depth as your practice matures. Start with the core columns and add optional ones only if you will actually keep them current, because an accurate five-column register beats an abandoned twelve-column one.
How do you create a risk register?
Run a risk identification session to capture each risk as a cause and effect, score each for likelihood and impact, and calculate a risk score to rank them. Choose a response (avoid, mitigate, transfer, or accept) for the top risks and assign each an owner. Then review the register on a set cadence, updating scores, closing resolved risks, and adding new ones, so it stays a live tool rather than a kickoff artifact.
What is the difference between a risk register and a risk management plan?
The risk register is the record of the actual risks, one row per risk. The risk management plan is the method that governs it: how risks will be identified, the scoring scales used, the review cadence, roles, and thresholds for escalation. The plan sets the rules; the register applies them. You write the plan once and update the register continuously.
What are the main categories in a risk register?
Common categories are schedule, budget or cost, technical, resource, external, and scope or requirements. Categorizing risks helps a review team spot patterns and look in the right places rather than reading a flat list. At portfolio level, categories like concentration and cross-project dependency also appear, because those exposures only become visible when you look across the whole set of projects.
What is the difference between a risk register and an issue log?
A risk register tracks things that might happen, with a likelihood attached. An issue log tracks things that have already happened and now need resolving. A risk moves from the register to the issue log the moment it materializes. Keeping them separate matters: the register is about prevention and early warning, while the issue log is about active problem-solving.