By Ryan Kramer, founder of Wisegrid. Last updated July 2026.
A risk register is a project management document that lists every identified risk to a project in one place, with each risk’s description, probability, impact, score, response strategy, owner, and status on its own row. It is the working record of the question “what could hurt this project, and what are we doing about each one?”, reviewed on a fixed cadence so answers stay current.
This guide gives you the column spec, the probability x impact scoring matrix, how qualitative risk analysis works, the response strategies, a complete worked example register, and how a risk register differs from a RAID log.
Key takeaways – A risk register is one row per risk with probability, impact, score, response, owner, and status. The template below is a complete starting point. – Write risks as cause and effect. “Because X, Y may happen, which would cost us Z.” Vague worries are not manageable risks. – Score = probability x impact, usually on 1 to 5 scales. The score’s job is sorting attention, not predicting the future. – There are four core responses to a threat: avoid, mitigate, transfer, accept, plus escalate when it is above your authority. “Mitigate everything” is not a strategy. – The register dies from staleness, not from bad scoring. Every risk needs an owner and a next-review date, and something has to happen when that date passes.
What is a risk register?
A risk register (also called a risk log) is the single, living list of a project’s identified risks: possible future events that would hurt scope, schedule, cost, or quality if they occurred. Each risk gets one row carrying everything needed to manage it: what it is, how likely, how bad, what we are doing about it, who is accountable, and when it will next be looked at.
It earns its keep in three ways: it forces risks out of hallway conversations and into writing while they are still cheap to handle, it ranks them so the weekly ten minutes of risk attention goes to the top of the list, and it creates accountability, because a risk with an owner and a review date behaves very differently from a risk everyone has merely heard about.
On formal projects (PRINCE2, PMBOK-style, or anything contractual) a register is usually mandatory. On informal projects it is still the highest-value fifteen minutes of setup you can do; the format tolerates being lightweight.
The risk register template
One sheet, one row per risk, these columns:
| Column | What goes in it |
|---|---|
| ID | Sequential (R-01, R-02…) so risks can be referenced in meetings |
| Risk description | Cause and effect: “Because [condition], [event] may occur, leading to [consequence]” |
| Category | Technical / schedule / cost / resource / external / vendor; pick a short fixed list |
| Date raised / raised by | When it entered the register and who spotted it |
| Probability (1-5) | How likely it is to occur, per the scale you define below |
| Impact (1-5) | How bad it would be if it occurred |
| Score | Probability x impact; sort the register by this column |
| Response strategy | Avoid / Mitigate / Transfer / Accept / Escalate |
| Response actions | The concrete next step, as a sentence with a name and a date in it |
| Contingency | What you will do if it occurs anyway (the fallback plan) |
| Owner | Exactly one name, with the authority to act |
| Status | Open / In progress / Occurred / Closed |
| Next review date | When this row must be looked at again |
Three template notes. The description format is load-bearing: forcing cause-effect wording weeds out unmanageable anxieties (“timeline is tight”) at the point of entry. Keep contingency separate from response actions; one is what you do now, the other is what you do if the risk fires. And when a risk occurs, do not delete the row; mark it Occurred and manage the resulting issue in your issue log, keeping the register honest about its own hit rate.
Scoring risks: the probability x impact matrix
Score each risk on two 1-to-5 scales and multiply. The point is consistent relative ranking, so define the scales in words, not just numbers, and put the definitions next to the register:
| Rating | Probability | Impact (example: schedule) |
|---|---|---|
| 1 | Rare (under ~10%) | Negligible; absorbed without plan changes |
| 2 | Unlikely (~10-30%) | Minor; slips days, no milestone moves |
| 3 | Possible (~30-50%) | Moderate; a milestone moves |
| 4 | Likely (~50-75%) | Major; the end date moves |
| 5 | Almost certain (over ~75%) | Severe; a contractual date or the business case is threatened |
The products form the classic 5×5 matrix. A common banding, which you should adjust to your project’s tolerance:
| Score | Band | Standing rule |
|---|---|---|
| 1-4 | Low | Monitor; review monthly |
| 5-9 | Moderate | Active response actions; review at the weekly meeting |
| 10-14 | High | Response plus contingency required; visible to the sponsor |
| 15-25 | Critical | Escalate immediately; sponsor decision on proceeding |
Two honest caveats. The scores are ordinal, not arithmetic: a 12 is not “three times worse” than a 4, it just sorts higher. And impact should be scored against the project’s most binding constraint; if you must hit a regulatory date, a cheap risk that moves the date outranks an expensive one that does not.
Qualitative risk analysis
What the previous section describes is qualitative risk analysis: rating each risk against defined descriptive scales and using the ranking to decide where response effort goes. It is “qualitative” because the ratings come from judgment against word-defined bands, not statistical modeling. For most projects it is the only risk analysis you need, and it is cheap: an hour with the right people at kickoff, minutes per week after.
Running it well:
- Rate with the people closest to the risk, not the PM alone. The engineer knows the API risk’s probability; finance knows the cost impact.
- Anchor on the definitions, not on gut numbers. “Is a milestone moving, or the end date?” produces more consistent scores than “is it a 3 or a 4?”
- Watch for the middle-heavy register. If everything scores 9, the scales are too vague to sort attention; sharpen the definitions and re-rate.
- Re-rate on a cadence. Probability and impact drift as the project moves; re-rate any row you touch weekly and everything quarterly.
Quantitative risk analysis (Monte Carlo simulation, expected monetary value) exists for projects that must defend large contingency budgets numerically. If nobody is asking for a confidence interval, qualitative analysis done consistently beats quantitative analysis done occasionally.
Risk response strategies
For threats, there are four core strategies, plus escalation:
- Avoid. Change the plan so the risk cannot occur: cut the risky feature, choose the proven vendor, re-sequence so the dependency disappears. The most powerful response and the most underused, because it means admitting part of the plan was wrong.
- Mitigate (reduce). Act now to lower probability or impact: prototype the risky integration first, add a review gate, book a second supplier. Most responses land here; the discipline is writing the mitigation as a real action with a name and a date, not “monitor closely.”
- Transfer. Move the impact to a third party better placed to carry it: insurance, fixed-price contracting, penalty clauses. Honest caveat: transfer moves the financial consequence, not the schedule consequence; if the vendor fails, your project is still late, you are just compensated for it.
- Accept. Decide the risk is tolerable, optionally holding contingency (time or money) against it. Acceptance is legitimate and often correct for low scores; silent acceptance is not. Write “Accepted” in the register so it is a decision, not an omission.
- Escalate. When the risk or its response is beyond your authority or budget, hand it to the sponsor or program level, and record who took it. Track it until someone with authority owns it.
The mirror set exists for opportunities (positive risks): exploit, enhance, share, accept. Most delivery registers reasonably track only threats; if you log opportunities, mark them clearly so the sort order still reads correctly.
Choose the strategy by comparing the cost of the response to the exposure. Spending $20K of engineering time to mitigate a risk whose realistic downside is a one-week slip is a bad trade; so is “accepting” a critical-band risk because the mitigation is inconvenient.
A complete risk register example
Mid-project register for a fictional warehouse management system rollout:
| ID | Risk description | Cat. | P | I | Score | Response | Actions | Owner | Status | Review |
|---|---|---|---|---|---|---|---|---|---|---|
| R-01 | Because the barcode scanner firmware is unreleased, hardware integration may slip past the Sep 1 pilot | Technical | 4 | 4 | 16 | Escalate + mitigate | Sponsor briefed Jul 3; parallel test rig on current firmware, decision on fallback scanners Jul 22 | Dana | In progress | Jul 12 |
| R-02 | Because peak season starts Nov 1, any go-live slip past Oct 15 forces a 3-month delay | Schedule | 3 | 5 | 15 | Mitigate | Cutover rehearsal moved up to Aug; go/no-go gate added Sep 20 | Ana | In progress | Jul 15 |
| R-03 | Because the warehouse team has one SQL-skilled analyst, data migration validation may bottleneck | Resource | 3 | 3 | 9 | Mitigate | Contractor shortlisted; validation scripts pair-built week of Jul 14 | Marcus | Open | Jul 14 |
| R-04 | Because the client’s network team is in a change freeze until Aug, VPN provisioning may block UAT | External | 2 | 4 | 8 | Transfer | Freeze exception request filed via client PMO Jul 2; their SLA is 10 business days | Dana | Open | Jul 16 |
| R-05 | Because forklift-mounted tablets run an older OS, the UI may need a compatibility pass | Technical | 2 | 2 | 4 | Accept | Accepted Jul 1; 3-day contingency held in the hardening sprint | Marcus | Open | Aug 1 |
| R-06 | Vendor pricing may rise at the Oct renewal before contract signature | Cost | 2 | 3 | 6 | Avoid | Renewal pulled forward; signature targeted Jul 30, removing exposure | Ana | In progress | Jul 20 |
What makes this a register rather than a list of worries: every description names a cause, every response is a named strategy with a dated action, R-05 shows acceptance done in writing with contingency held, and R-01 shows escalation working alongside mitigation rather than instead of it.
Risk register vs RAID log
The two documents overlap on exactly one letter, and teams regularly ask which they need.
A risk register covers risks only, in depth: categories, scoring definitions, response strategies, contingency plans, sometimes contingency budgets. A RAID log covers four things lightly: Risks, Assumptions, Issues, and Dependencies in one combined list, where the risk rows carry a score and an owner but usually not formal response strategies or contingency plans.
Choosing between them: run a RAID log when you want one document for a normal project’s weekly review (its risk section is a lightweight register, and that is usually enough); run a full risk register when risk depth is required by contract, methodology, or program-level reporting, or when risks carry contingency budgets that need defending. If you run both, the register is the source of truth for risks and the RAID review reads its top rows; the same risk living in two documents with two scores means one of them is fiction.
Whichever you run, risks are future events and issues are present ones; when a risk fires, it leaves the risk list and becomes a managed issue.
How to keep the register alive
- Review weekly, sorted by score. Ten minutes at the regular project meeting: top risks first, every open row past its review date gets touched.
- Add at the moment of mention. “One thing that worries me…” in any meeting is a risk being raised; capture it then, score it later.
- Make the owner column mean something. The owner drives the response and re-rates the risk. If one name owns everything, the register is the PM’s diary, not a management tool.
- Close and record outcomes. Expired risks get a one-line closing note; fired ones get marked Occurred. Both build the calibration that improves next project’s scoring.
- Feed status reporting from the register. The report’s “top risks” section should be the register’s top rows, verbatim. Two independently maintained risk lists diverge within a month.
And name the real failure mode: registers die of missed review dates, not bad scoring. The next-review column only works if something happens when the date passes, which is the one job a spreadsheet cannot do for you.
A risk register that maintains itself
Built as a Wisegrid sheet, the register does its own chasing: date-triggered automations catch every risk whose next-review date has passed and notify its owner, with a run history that shows every nudge actually fired; a dashboard rolls up open risks by score band and category so the sponsor view is always current without anyone assembling it; and cross-sheet references pull the top-scored rows straight into your status report sheet, so the report and the register cannot disagree.
The step-by-step build, from the column setup and scoring formulas to the stale-risk automation and the sponsor dashboard, is in the companion guide: How to build a self-maintaining risk register in Wisegrid.
FAQ
What is a risk register in project management?
A living document listing every identified project risk, one row each, with probability, impact, score, response strategy, owner, status, and next review date. Its job is ranking risk attention and making responses accountable.
What are the 4 risk response strategies?
For threats: avoid (change the plan so the risk cannot occur), mitigate (reduce probability or impact), transfer (move the consequence to a third party), and accept (tolerate it, in writing). Escalate is the fifth option when the risk exceeds your authority.
What is the difference between qualitative and quantitative risk analysis?
Qualitative analysis rates risks against defined descriptive scales (the 1-5 ratings here) to rank them. Quantitative analysis models risks numerically (simulation, expected monetary value) to size contingency. Most projects need only consistent qualitative analysis.
What is the difference between a risk register and a risk matrix?
The matrix is the 5×5 scoring grid used to rate and band risks; the register is the document that holds the risks themselves.
How often should a risk register be reviewed?
Weekly for the top of the list, as part of the standing project meeting, with every row carrying its own next-review date. High-exposure phases justify tightening that cadence.
Who owns the risk register?
The project manager owns the document, its cadence, and its hygiene. Each risk has its own owner who drives the response; spreading that ownership is what keeps the review from being a monologue.
Build a risk register that chases its own review dates
Copy the template into a sheet, wire the stale-risk automation once, and the register stops depending on anyone’s memory.
Start free → · How to build it in Wisegrid → · RAID log template →
About the author Ryan Kramer is the founder of Wisegrid, a higher-capacity Smartsheet alternative built around a 1,000,000-cell-per-sheet grid, date-triggered automations with run history, and cross-sheet reporting. He writes about the project management documents teams actually keep updated. More from Ryan →