Project Risk Register: The 5×5 That Decides What You Worry About
A risk register is a triage table, not a box of fears. Rank every risk as probability × impact, hand each one an owner and a response strategy, and let the score tell you which five problems on the page actually deserve tonight.
Every project has a dozen things that could go wrong, and most teams write them all down in the same breathless laundry list — then file it. That’s not risk management; that’s a collection of anxieties with a date on it. A risk register becomes useful the moment it starts ranking: a 5×5 grid that turns “this might fail” into a number, a strategy, and a name. High-probability, high-impact items get an active response with a time-budgeted contingency; low-probability, low-impact concerns get monitored from a watch-list and nothing else. This guide shows you the fields that make a register a working tool, the probability–impact scoring that decides your priorities, and a template you can run in Excel.
What a Risk Register Actually Holds
Not every column earns its place. A working register carries ten fields — anything more is ceremony, anything less hides decisions:
| Field | Purpose |
| Risk ID | A short reference for tracking |
| Description & trigger | What could go wrong, and the condition that sets off the response |
| Category | Technical, schedule, resource, scope, external |
| Probability (1–5) | How likely it is |
| Impact (1–5) | How much damage if it happens |
| Risk score | Probability × Impact |
| Response strategy | Avoid / Transfer / Mitigate / Accept |
| Owner | One person accountable for tracking and acting |
| Planned actions | Concrete steps the response requires |
| Status | Open, being handled, closed, materialized |
The description matters more than most teams realize. A good entry says“If the payment gateway API changes its authentication method (trigger), we may not be able to process transactions (consequence)”— not “payment gateway risk.” The trigger is what makes monitoring actionable later.
Score With the 5×5 Matrix
Score each risk 1–5 on probability and 1–5 on impact, then multiply.
| Impact 1 | Impact 2 | Impact 3 | Impact 4 | Impact 5 | |
| Prob. 5 | 5 | 10 | 15 | 20 | 25 |
| Prob. 4 | 4 | 8 | 12 | 16 | 20 |
| Prob. 3 | 3 | 6 | 9 | 12 | 15 |
| Prob. 2 | 2 | 4 | 6 | 8 | 10 |
| Prob. 1 | 1 | 2 | 3 | 4 | 5 |
The rules are simple, and ONES states them plainly:
- Red zone (16–25):active response now — avoid or transfer, with an immediate plan.
- Yellow (6–15):mitigate, with a contingency reserve where warranted.
- Green (sub-6):accept and monitor from a watch-list.
A low-probability, extreme-impact item — say, a data-center outage — still lands high through impact alone, even if probability is 1. That’s the point of the matrix: it forces the “unlikely but catastrophic” items to sit with the “likely but trivial” ones instead of hiding.
Choose a Strategy Per Risk
For everythreatthat clears your threshold, pick one of four classic responses:
- Avoid— change the plan so the risk disappears (fall back to a mature technology instead of an unproven one).
- Transfer— shift the impact to a third party (insurance, outsourcing with a fixed-price contract). You can’t transfer reputation damage.
- Mitigate— reduce probability or impact (build a graceful fallback, cross-train a second owner, add a pre-review).
- Accept— log it and move on when the cost of action exceeds the potential damage, but set a trigger for re-evaluation.
Opportunitiesare risks with a positive spin and get their own playbook:exploit(make it happen),enhance(increase the odds),share(bring in a partner), oraccept. Leaving opportunities out of the register is leaving upside on the table.
Run It Through the Worked Example
A payment-integration project starter register might read:
| ID | Risk | P | I | Score | Strategy | Owner |
| R1 | App-store review runs long | 3 | 4 | 12 | Mitigate: submit a pre-review build early | Product |
| R2 | Key developer leaves mid-sprint | 2 | 5 | 10 | Mitigate: cross-train + document core modules | Tech Lead |
| R3 | PCI compliance delayed | 4 | 5 | 20 | Avoid/Transfer: certified vendor + fixed contract | PM |
| R4 | Minor UI glitch recurs | 4 | 2 | 8 | Accept: log and monitor | QA |
| R5 | API vendor deprecates version | 3 | 4 | 12 | Transfer: vendor SLA + fallback adapter | Architecture |
R3 is the one that gets tonight’s attention; R4 gets a watch-list row and nothing else. A team that treats R1–R5 as equals spends its energy on the wrong five problems.
Build a Risk Register in Excel
- Register sheet— the ten columns above, one row per risk.
- Score column— a simple=probability*impactformula so the priority re-sorts itself as scores change.
- Conditional formatting— color the score cell red ≥16, yellow ≥6, green below, so the page reads at a glance.
- Owner & status columns— a blank owner is the #1 sign the register is decorative.
- Review rhythm— review at every sprint retrospective or monthly check-in; update scores, close dead risks, escalate live ones.
Where a Risk Register Fails
- It goes stale.Scores and triggers untouched for months is a list of yesterday’s worries.
- Scores are faked.When the discussion behind the number is skipped, the score becomes a rubber stamp instead of an alignment tool.
- No owner.A risk with a blank owner has no one to act — assign one person who owns the outcome, not just executes.
- No trigger.Without“if X happens, do Y,”monitoring is vague and the response arrives late.
- Everything is equal.Trying to actively manage all 20 risks means you manage none — focus the top 3–5 per review.
Frequently Asked Questions
How is a risk score calculated?Probability (1–5) × Impact (1–5). Scores of 16–25 demand an active response; low scores get monitored.
Who should own a risk?One person accountable for tracking it and executing the response. They don’t have to do all the work — they own the outcome and can delegate the tasks.
What’s the difference between threats and opportunities?Threats use avoid/transfer/mitigate/accept; opportunities use exploit/enhance/share/accept. Both belong in the register.
How often should I review the register?At least every sprint or monthly. Risks that were low can turn serious overnight, so the review is the discipline, not the list.
Do I need special software?No. A spreadsheet with a score formula and conditional formatting works for most teams; specialized tools just add the automation and the shared visibility.
Make the List Earn Its Keep
The difference between a risk register and a worry list is the score, the strategy, and the owner. Score and color them, assign a response and a name, review on a fixed rhythm, and the page becomes a decision tool instead of a dusty appendix.
Keep the reviewing cadence against amonthly budget planner habitso risk check-ins actually recur, and log any contingency spend to areceipt-style expense trackerso mitigation costs are facts, not surprises. More free tools live atUse Office Toolkit.