A risk matrix is a grid that scores every risk on two dimensions, how likely it is to happen and how much damage it would do, and turns those two scores into a single rating. The rating then decides three things: who owns the risk, what you are obliged to do about it, and how often somebody has to look at it again. The most common form is five levels on each axis, which is where the phrase 5x5 risk matrix comes from.
The grid is the easy part and you can draw it in a minute. The part that determines whether the matrix is useful or decorative is the pair of written scales underneath it. If "high impact" is not defined in dollars, days, and named consequences, then two competent people will score the same risk two or three levels apart, the ratings become uncomparable across projects, and the portfolio view built on top of them is a colored picture with no information in it.
Key takeaways
- Write the scales before you draw the grid. Undefined levels are the single biggest cause of useless risk matrices.
- Impact needs several columns, not one. A risk can be trivial for cost and severe for compliance, and you score the worst one.
- The score is not the output. The response threshold is. A rating that does not trigger a mandatory action changes nothing.
- 5x5 gives you room to discriminate. 3x3 pushes almost everything into the middle box, which is where risks go to be ignored.
- Score the risk twice: before treatment and after. The gap between inherent and residual is the evidence your mitigation actually did something.
What is a risk matrix?
A risk matrix is a tool for qualitative risk analysis that ranks risks by combining a probability score with an impact score. Each risk is placed in one cell of the grid, the cell carries a rating such as low, medium, high, or critical, and that rating drives the response. It is a prioritization device rather than a measurement device: it tells you which risks deserve attention first, not what any of them will actually cost.
The names vary and all describe the same object. Risk assessment matrix, probability and impact matrix, risk severity matrix, risk analysis matrix, and risk rating matrix are used interchangeably. When the grid is shaded red through green and used to show a whole portfolio at once, people usually call it a risk heat map. The underlying mechanics do not change.
What a risk matrix is not is a quantitative model. It does not tell you the expected monetary value of a risk, and the numbers in the cells are ordinal, not real. A five is worse than a four but not "one worse", and multiplying a probability score by an impact score gives you a useful ordering rather than a meaningful quantity. That distinction matters most when somebody sums the scores across a portfolio and presents the total as if it meant something. It does not.
The 5x5 risk matrix
Here is the standard grid, with the product of the two scores in each cell and the rating band it falls into. Probability runs down the side, impact across the top.
| Probability | 1 Negligible | 2 Minor | 3 Moderate | 4 Major | 5 Severe |
|---|---|---|---|---|---|
| 5 Almost certain | 5 Medium | 10 High | 15 High | 20 Critical | 25 Critical |
| 4 Likely | 4 Low | 8 Medium | 12 High | 16 Critical | 20 Critical |
| 3 Possible | 3 Low | 6 Medium | 9 Medium | 12 High | 15 High |
| 2 Unlikely | 2 Low | 4 Low | 6 Medium | 8 Medium | 10 High |
| 1 Rare | 1 Low | 2 Low | 3 Low | 4 Low | 5 Medium |
Swipe to see more →
Notice that the bands are not a straight cut on the product. A rare but severe risk scores 5 and is rated medium, while an almost certain but negligible risk also scores 5 and is also medium. That symmetry is often wrong for real projects, and many organizations deliberately skew the bands upward in the high impact column, so that anything scoring 5 on impact gets at least a medium regardless of probability. If a single occurrence would end the project, "unlikely" is not a reason to stop watching it. Decide which convention you use and write it down, because teams silently apply different ones and then argue about the output.
How to write the probability scale
Probability is the easier of the two scales to define and the one most often left as adjectives. Adjectives do not survive contact with a room of five people. Give each level a percentage band and a plain English test.
| Level | Label | Band | The test |
|---|---|---|---|
| 5 | Almost certain | Over 80 percent | You would be surprised if it did not happen. It has happened on the last two similar projects |
| 4 | Likely | 50 to 80 percent | More likely than not on the evidence you have today |
| 3 | Possible | 20 to 50 percent | A realistic scenario with a plausible chain of events behind it |
| 2 | Unlikely | 5 to 20 percent | Would need something to go wrong that usually does not |
| 1 | Rare | Under 5 percent | Would need an unusual combination of events. You are logging it because the impact is high, not because you expect it |
Swipe to see more →
Two rules make these bands work. First, always score probability over a stated window, normally the remaining life of the project, otherwise "likely" is meaningless. Second, anchor the score to something observed rather than felt: how often this has happened before, on how many of the last similar projects, or what the supplier's actual delivery record looks like. Estimates anchored to history move much less between reviewers than estimates anchored to confidence.
How to write the impact scale
Impact is where matrices actually fail, because a single "impact" column forces people to average unlike things. Split it into the consequence types your organization genuinely cares about and score the worst one. Four or five columns is enough. The thresholds below are illustrative; set yours from the size of your own projects.
| Level | Cost | Schedule | Benefits | Compliance and reputation |
|---|---|---|---|---|
| 5 Severe | Over 20 percent of budget | Milestone missed by more than a quarter | Business case no longer viable | Reportable breach, regulator engagement, or national press |
| 4 Major | 10 to 20 percent | Key milestone missed, go live moves | Benefits cut by more than a third | Audit finding, formal customer complaint |
| 3 Moderate | 5 to 10 percent | Float consumed, critical path at risk | Benefits delayed by a quarter | Internal escalation, control gap noted |
| 2 Minor | 1 to 5 percent | Absorbed within existing float | Minor reduction, recoverable | Handled within the team |
| 1 Negligible | Under 1 percent | No measurable effect | No effect | No effect |
Swipe to see more →
Score across the row and take the highest, never the average. A data handling risk that costs almost nothing and delays nothing but produces a reportable breach is a five, and averaging it against three ones would bury it at a two. This single rule catches most of the risks that organizations later describe as having come out of nowhere.
The benefits column is the one most project teams omit and the one a portfolio function should insist on. A risk that leaves the project on time and on budget while quietly removing half the benefit is invisible on a cost and schedule matrix, and it is exactly the risk that shows up two years later in a post implementation review. If your organization tracks a business case at all, it belongs on the impact scale.
What each rating obliges you to do
A rating that does not trigger anything is decoration. Bind each band to a named owner, a required response, and a review frequency, and publish the table as part of the risk process.
| Band | Score | Owned by | Required response | Reviewed |
|---|---|---|---|---|
| Critical | 16 to 25 | Sponsor, escalated to the steering committee at the next meeting or sooner | Documented mitigation with dates and a named actioner, plus a fallback plan if mitigation fails | Weekly |
| High | 10 to 15 | Project manager, visible on the portfolio report | Active mitigation with an owner and a target residual score | Fortnightly |
| Medium | 5 to 9 | Project manager | Mitigation planned, or a written and accepted decision not to act | Monthly |
| Low | 1 to 4 | Workstream lead | Accept and monitor. No mitigation effort required | At each stage gate |
Swipe to see more →
The row that changes behavior most is the medium one, specifically the words "or a written and accepted decision not to act". Without that clause, medium risks accumulate silently for months. With it, somebody has to put their name to leaving a risk alone, which is a surprisingly effective filter. Those acceptance decisions should land in the same place as every other governance decision, which for most organizations is the decision log inside the project governance framework.
Inherent risk, residual risk, and why you score twice
Score every risk twice. The inherent score is the rating with no mitigation in place. The residual score is the rating you expect once the planned mitigation is working. Both go in the register, in separate columns.
This is not bureaucratic duplication. It is the only way to see whether risk work is achieving anything. A mitigation plan that costs three weeks of effort and moves a risk from 16 to 15 is not a mitigation plan, it is activity, and the two columns make that visible in a way a narrative update never does. It also gives you a clean way to prioritize mitigation spend: sort by the size of the gap between inherent and residual, divided by the cost of getting there, and work down the list.
The residual score is also what should appear on the status report. Reporting inherent scores makes every project look like it is on fire and trains executives to ignore the risk section entirely. Report residual, keep inherent in the register, and show both only for critical risks where the mitigation itself might fail.
Risk matrix example: a finance system replacement
Six real shaped rows from a nine month finance system replacement, scored on the scales above. Probability and impact are P and I, the score is the product, and residual is the expected rating once mitigation lands.
| Risk | P | I | Score | Band | Mitigation | Residual |
|---|---|---|---|---|---|---|
| Historic transaction data fails validation during migration, delaying cutover | 4 | 4 | 16 | Critical | Two trial migrations against production volumes, first one eight weeks before cutover | 8 Medium |
| Integrator loses its lead consultant to another engagement | 3 | 4 | 12 | High | Named substitute and knowledge transfer clause written into the statement of work | 6 Medium |
| Controller's team cannot staff the parallel run alongside quarter end close | 4 | 3 | 12 | High | Parallel run rescheduled clear of close; two temporary staff funded from contingency | 4 Low |
| Works council consultation on shared services roles is not complete before go live | 3 | 5 | 15 | High | Consultation started in month two; sponsor holds the relationship directly | 5 Medium |
| Personal data is copied to a supplier test environment without a processing agreement | 2 | 5 | 10 | High | Anonymized test data set; legal sign off gate before any environment is populated | 5 Medium |
| Chart of accounts redesign slips, forcing a like for like migration and losing the reporting benefit | 3 | 4 | 12 | High | Design frozen at the month four gate; scope of the redesign cut to the two divisions that drive the benefit | 8 Medium |
Swipe to see more →
Three of those rows illustrate points the grid alone will not teach you. The data protection risk is unlikely and severe, scoring 10, and under a naive banding it would sit below several routine delivery risks; the impact column is what pulls it into the high band where it belongs. The works council risk scores 15 largely because a single named stakeholder holds a veto, which is the kind of exposure a stakeholder map surfaces weeks before a risk workshop does. And the chart of accounts row is a benefits risk rather than a delivery risk, which is precisely the type that disappears from a matrix scored only on cost and time.
3x3 or 5x5: which size of matrix
| 3x3 | 5x5 | |
|---|---|---|
| Best for | Small projects, early scoping, workshops with non specialists | Programs, portfolios, anything where risks are compared across projects |
| Main weakness | Central clustering. Most risks land in the middle box and stop being distinguishable | False precision. A four versus a three gets debated as though the difference were measurable |
| Discrimination | Nine cells, four practical bands, coarse | Twenty five cells, four bands, enough spread to sort a top ten |
| Effort to run | Minutes. No written scales strictly needed | Requires written scales, which is the real cost and also the real benefit |
Swipe to see more →
Use 5x5 wherever risk scores are compared between projects, which is any portfolio setting, because 3x3 will not separate the top ten from the middle forty. Use 3x3 for a one hour workshop where the aim is to find the risks rather than rank them precisely. What does not work is mixing them inside one portfolio and then converting between the two, because the conversion invents precision that was never there.
Risk matrix, risk register, and RAID log
| Artifact | What it is | What it answers |
|---|---|---|
| Risk matrix | The scoring grid and the two scales behind it | How bad is this risk relative to the others, and what does that oblige us to do |
| Risk register | The list of risks, with owners, scores, mitigations and dates | What are our risks and who is doing what about each one |
| RAID log | The working log covering risks, assumptions, issues and dependencies together | What is open across all four categories on this project right now |
| Portfolio risk management | The process that runs across every project plus the risks that exist only at portfolio level | What threatens the portfolio as a whole, including concentration and dependency risk |
Swipe to see more →
The relationship is simple once stated: the matrix is the ruler, the register is the list the ruler is applied to, and the RAID log is where the register lives on projects that keep all four categories in one place. You need one matrix per organization, not one per project, and that is the entire point of standardizing the scales.
How a PMO uses risk matrices across a portfolio
A single project's matrix is a prioritization aid. Twenty projects using the same matrix become something a portfolio function can actually manage, and it depends entirely on the scales being shared. Once they are, three things become possible.
You can rank across projects. A high on project A means the same thing as a high on project B, so a portfolio top ten is meaningful rather than a reflection of which project manager scores most pessimistically. Without shared scales this ranking is worse than useless, because it looks credible.
You can spot concentration. Nine projects each carrying a moderate risk against the same supplier is a severe portfolio risk that appears nowhere on any individual matrix. Tagging every risk with a cause category, such as supplier, capacity, regulatory, or technical, and then counting by category across the portfolio is a ten minute monthly exercise that finds exposures no project could see. Capacity is usually the biggest offender, which is why portfolio risk and capacity planning should be reviewed in the same meeting.
And you can calibrate. Once a quarter, take ten risks that actually materialized and check what they had been scored beforehand. If the things that hit you were consistently sitting at medium, your probability scale is optimistic and needs adjusting. Almost nobody does this, and it is the only feedback loop that stops a risk process drifting into ritual. It pairs naturally with whatever your portfolio review meeting already covers on delivery performance.
Where risk matrices go wrong
| The failure | What it looks like | The fix |
|---|---|---|
| Undefined scales | "High impact" means whatever the person filling it in thinks | Write the bands in dollars, days and named consequences before scoring anything |
| One impact column | A compliance risk averaged down to a two because it costs nothing | Several consequence columns, score the worst |
| Central clustering | Forty of fifty risks rated medium | Move to 5x5, and require a justification for any score of three on both axes |
| Scoring once | Every risk still shows its inherent rating in month seven | Separate inherent and residual columns, and report residual |
| Ratings with no consequence | Critical risks with no fallback plan and no escalation | Bind every band to a required response and a review frequency |
| Summing the scores | "Portfolio risk score: 412", presented as a trend | Ordinal scores cannot be added. Count risks by band instead |
| Issues logged as risks | Things that have already happened sit in the matrix at probability five | If it has happened it is an issue. Move it and manage it differently |
Swipe to see more →
That last one is worth watching in every review. A risk at probability five is almost always an issue that nobody wanted to reclassify, because reclassifying it means admitting something went wrong. The tell is a risk that has sat at 20 or 25 for three consecutive reviews with a mitigation plan that never changes.
Frequently asked questions
What is a 5x5 risk matrix?
A 5x5 risk matrix is a grid with five probability levels and five impact levels, producing twenty five cells and scores from 1 to 25. Each score falls into a band, typically low, medium, high, or critical, and the band determines who owns the risk and what response is required. It is the standard size wherever risks from different projects need to be compared.
How do you calculate a risk score?
Multiply the probability score by the impact score. On a 5x5 matrix a risk scored likely (4) with major impact (4) gives 16. Take the impact from the worst affected consequence type rather than an average across them. The resulting number is an ordinal rank for sorting risks, not a quantity, so it should never be summed or averaged across a portfolio.
What are the 5 levels of risk?
On the probability axis the five levels are usually rare, unlikely, possible, likely, and almost certain, each tied to a percentage band. On the impact axis they are negligible, minor, moderate, major, and severe, each tied to thresholds in cost, schedule, benefits, and compliance. The overall rating bands are commonly low, medium, high, and critical.
What is the difference between a risk matrix and a risk register?
The risk matrix is the scoring tool: the grid plus the written probability and impact scales that define each level. The risk register is the list of actual risks with their owners, scores, mitigations, and review dates. One matrix serves a whole organization; each project keeps its own register and applies the shared matrix to it.
What is a risk heat map?
A risk heat map is a risk matrix shaded by severity, usually green through amber to red, with risks plotted as dots in the cells. It is the same tool presented for an audience rather than for scoring, and it works well on a portfolio dashboard because the concentration of dots in the top right corner is readable in about two seconds.
What is the difference between qualitative and quantitative risk analysis?
Qualitative analysis ranks risks using judgment based scales, which is what a risk matrix does, and it is fast enough to apply to every risk on a project. Quantitative analysis models the actual numbers, using techniques such as expected monetary value or Monte Carlo simulation on the schedule, and it is normally reserved for the handful of critical risks where the modeling effort is justified.
How often should a risk matrix be reviewed?
Review individual risk scores at a frequency set by their band: weekly for critical, fortnightly for high, monthly for medium, and at each stage gate for low. The matrix itself, meaning the scales and the thresholds, should be reviewed annually or after any significant change in the size of projects the organization runs, since impact bands set for small projects distort quickly.
Who owns the risk matrix?
The PMO or risk function owns the matrix, because its value comes from every project using the same scales. Individual risks are owned by named people, with critical risks owned by the sponsor rather than the project manager. A project manager who can quietly redefine what "major impact" means has removed the only thing that made cross project comparison possible.
What colors are used in a risk matrix?
Convention is green for low, yellow or amber for medium, orange for high, and red for critical, running from the bottom left of the grid to the top right. Color should never be the only signal, since a meaningful share of readers cannot reliably distinguish red from green, so always print the band name and the numeric score alongside the shading.
Can a low probability risk still be a high risk?
Yes, and handling this well is what separates a serious risk process from a ritual one. A rare event with severe consequences, such as a reportable data breach, deserves a high rating even though it is unlikely, which is why many organizations skew their bands so that any impact score of five reaches at least medium regardless of probability. Decide the rule in advance and document it.
Last updated August 2026