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.
On a smaller project a full register is often more machinery than the risk justifies, and the lighter alternative is a RAID log, which carries risks alongside assumptions, issues and dependencies at one sentence per row. Use the register when a quantified exposure figure matters and someone will act on it. Use the lighter log when what you need is weekly attention rather than analysis. Large and regulated projects run both, for different meetings.
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.
The standard risk register columns to include
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 |
Swipe to see more →
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 |
Swipe to see more →
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 |
Swipe to see more →
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 |
Swipe to see more →
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.
How often to review the risk register
A register that is written once and reviewed when someone remembers is a document, not a control. The review cadence is what turns it into one, and the cadence should be set by exposure rather than by habit. Most projects need less frequent review than a monthly meeting implies, and the two or three that matter need considerably more.
| Project tier | Full register review | Red and high risks | Reviewed by |
|---|---|---|---|
| Major or high exposure | Every two weeks | Weekly, in the delivery meeting | Project manager plus named risk owners |
| Standard delivery project | Monthly | Every two weeks | Project manager plus workstream leads |
| Small or short duration | At each stage boundary | Monthly | Project manager |
| Portfolio level aggregation | Quarterly | Monthly | PMO, reported to the steering committee |
Swipe to see more →
Two rules make the cadence stick. First, the review is a scheduled event with an owner, not an agenda item that gets dropped when the meeting overruns. Second, every risk carries a next review date in the register itself, so a risk that has not been looked at since March is visible as a data field rather than something you would only notice by reading the whole document.
Beyond the calendar, four events should trigger a review regardless of when the last one happened: a stage or gate boundary, any significant change to scope or schedule, a risk materializing into an issue, and a change of project manager or sponsor. That last one is the most commonly skipped and the most valuable, because an incoming manager inherits a register full of assessments made by someone whose reasoning they cannot see.
The risk review meeting agenda
The risk review is a working session, not a read out. If the register is projected on screen and walked top to bottom, the meeting will spend its energy on rows one to eight and run out of time before reaching anything that has been deteriorating quietly. Sort by what needs attention, and give the session a fixed shape.
| # | Agenda item | Time | Required output |
|---|---|---|---|
| 1 | Risks that changed score since the last review, in either direction | 10 min | Confirm the new score and whether the response still fits |
| 2 | Risks whose mitigation actions are overdue | 10 min | A new date with the owner present, or an explicit decision to accept the risk |
| 3 | Risks with no movement in three or more reviews | 8 min | Close it, escalate it, or accept it. It does not stay as it is. |
| 4 | New risks raised since the last session | 10 min | Scored, owned, and given a response type |
| 5 | Risks proposed for closure | 5 min | Closed with the reason recorded, or kept open with a review date |
| 6 | Anything needing escalation | 5 min | Named recipient and the date an answer is required |
Swipe to see more →
Item three is the one most teams do not have and the one that does the most work. A risk that has sat at amber with the same mitigation for four consecutive reviews is not being managed, it is being stored. Forcing the choice between closing it, escalating it, and formally accepting it clears more register clutter in one session than any tidying exercise, and it surfaces the risks that the project genuinely cannot handle on its own.
Keep the session to the risks and let the register carry the detail. A risk review that turns into a status update has been captured by whichever attendee has the most to explain, and the risks that nobody wants to discuss are exactly the ones that quietly drop off the end of the agenda.
Running a risk identification workshop
The register has to be populated before it can be reviewed, and a workshop at the start of a project or stage produces a better register than asking people to submit risks by email. A facilitated session of ninety minutes with the right mix of people typically surfaces two to three times more genuine risk than a round of individual submissions, mostly because risks that cross team boundaries only become visible when the boundaries are in the same room.
A workable format:
- Invite people who will actually see the risk first. Delivery leads, the operations team who will run the result, one person from any dependent team, and the sponsor for the last twenty minutes only. The sponsor's early presence suppresses exactly the risks you called the session to find.
- Prompt by category rather than asking for risks in the abstract. Walk the categories the register already uses: delivery, technical, resource, vendor and third party, regulatory, dependency, adoption. An open question produces silence, then three obvious risks. A category prompt produces a list.
- Capture without scoring. Scoring during identification kills the flow, because people start arguing about probability instead of naming exposures. Write everything down, then score in a second pass.
- Score in the room, assign owners in the room. A risk that leaves the workshop without a named owner will not have one a month later. The owner is the person who can act on it, never the project manager by default.
- Deliberately look for the risks nobody wants to raise. Ask directly: what would have to be true for this project to fail, and what do we currently believe that we have not checked? The optimism that makes projects get approved is the same optimism that keeps their registers thin.
Repeat the exercise at each major stage boundary rather than only at the start. The risks that matter at design time are almost entirely different from the ones that matter at cutover, and a register built once at initiation ages into irrelevance without anyone noticing that it has.
Register staleness shows whether the register is alive
The register's size tells you nothing. A hundred rows can mean thorough analysis or a dumping ground that nobody prunes. The more useful measure is how much of it is actually moving.
Register staleness is the share of open risks whose score, mitigation, or status has not changed across the last three reviews. It is easy to compute from the register's own history and it is very hard to game, because improving it requires either doing something about a risk or honestly closing it.
| Stale share of open risks | What it usually means | Response |
|---|---|---|
| Under 20 percent | The register is a live control. Risks arrive, move, and close. | Nothing. Keep the cadence. |
| 20 to 40 percent | Normal for a long project, but the tail is starting to build. | Apply the three review rule in the next session and clear the backlog. |
| Over 40 percent | The register is being maintained for audit rather than used for decisions. | Close or accept the dormant rows, then check whether risk owners were ever briefed. |
| Over 60 percent with no closures in a quarter | Nobody is reading it. The reviews are happening on paper only. | Rebuild from a fresh identification workshop rather than trying to salvage it. |
Swipe to see more →
These bands are an operating rule to calibrate against your own history rather than an industry constant. Measure your own staleness for two quarters and the threshold that matters for your projects will be clear enough. The point of tracking it is that it distinguishes a register nobody uses from a register that is genuinely quiet, and those two look identical from the outside.
Five ways a risk register stops being used
Everything is scored medium. When scoring has no consequence, the safest answer is the middle one, and a register where nothing is high is a register that will never trigger an escalation. Fix it by requiring that the top three risks are named explicitly at every review, which forces a ranking whether or not the scores support one.
The owner is always the project manager. A risk owned by the person running the meeting is a risk owned by nobody in particular. Ownership should sit with whoever can actually reduce the exposure, even when that person is outside the project team, and especially when they are.
Mitigations are described but never scheduled. A mitigation without a date and an owner is an intention. The register should carry mitigation actions with dates, and overdue mitigations should appear on the agenda as their own item rather than being noticed in passing.
It is written for the audit rather than the team. Registers that exist to satisfy an assurance requirement are complete, well formatted, and read by nobody. The tell is that risks are never closed, because closing one looks like reducing coverage.
Risks and issues are kept in the same list. Once they are mixed, the issues dominate every conversation, because issues are happening now and risks are hypothetical. The register loses its early warning function within about two months.
Frequently asked questions
What does a project risk register contain?
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.
How often should a risk register be reviewed?
Review cadence should follow exposure rather than habit. Major projects warrant a full review every two weeks with red risks checked weekly, standard projects monthly, and small projects at each stage boundary. Portfolio level aggregation is usually quarterly. Four events should trigger a review regardless of the calendar: a stage boundary, a significant scope or schedule change, a risk materializing, and a change of project manager or sponsor.
Who is responsible for maintaining the risk register?
The project manager owns the register as a document and makes sure reviews happen, but each individual risk needs a named owner who can actually act on it. That owner is often outside the project team. Assigning every risk to the project manager by default is the most common reason registers stop producing action, because the person running the review is also the person accountable for every line in it.
What happens in a risk review meeting?
A risk review works through risks that changed score, mitigations that are overdue, risks with no movement across three or more reviews, newly raised risks, proposed closures, and anything needing escalation. It is a working session, not a read out of the full register. The most valuable item is the dormant risk check, which forces each stalled risk to be closed, escalated, or formally accepted.
How do you run a risk identification workshop?
Invite the people who would see a risk first, prompt by risk category rather than asking for risks in the abstract, capture everything before scoring anything, then score and assign owners in the room. Keep the sponsor out until the final twenty minutes so the session surfaces the risks people are reluctant to raise upward. Repeat at each stage boundary, since the risks that matter at design time differ from those at cutover.
Where this fits
The register is the project level artifact in a chain that runs upward. It draws from and feeds the RAID log, which carries risks alongside assumptions, issues, and dependencies, and the register template itself is usually issued with the RAID log template. Scoring uses the risk matrix, dependency exposure between projects is worked through project dependency management, and aggregated exposure across the funded set belongs to project portfolio risk management.
Operationally, changed and escalating risks are raised in the project status meeting, reported through RAG status and the portfolio status report, and escalated to the steering committee when the response needs authority the project does not have. Risks that turn out to be chronic rather than specific usually justify an independent project health check, and the assumptions recorded at the start are set out in the project charter. The discipline all of this sits inside is project portfolio management.