Cox, NIST SP 800-30 and BSI Standard 200-3 each show why a likelihood-and-impact grid can sort and communicate risks but cannot measure them. What makes one defensible is the record you keep beside it.
BSI Standard 200-3, the German federal office's method for risk analysis under IT-Grundschutz, prints a risk matrix in §5.2. The next sentence says what the matrix is for: "It is simply used to illustrate the following examples and should be adapted to the individual needs".
The section before it is more candid still. BSI recommends that "not more than five categories should be chosen" per axis, then reports what happens in practice: "The majority of users even tends to de facto work with only two categories per dimension, for example "Limited" and "Considerable"."
So the most copied picture in risk management comes from its publisher with instructions to adapt it, and by its publisher's account most people using it work with a two-by-two. The matrix is still useful, once you know what kind of object it is: a way to sort a register and to talk about it, with no claim to measure anything.
NIST SP 800-30 Rev. 1, the US guide for conducting risk assessments, separates three approaches in §2.3.2. Its description of the qualitative one fits most risk matrices:
"This type of assessment supports communicating risk results to decision makers. However, the range of values in qualitative assessments is comparatively small in most cases, making the relative prioritization or comparison within the set of reported risks difficult."
A register with numbered scales is what NIST calls semi-quantitative: "bins, scales, or representative numbers whose values and meanings are not maintained in other contexts." A 7 on your impact scale means something inside your assessment. Outside it, a 7 carries no meaning.
Both texts say how to make the ratings repeatable. NIST: "The repeatability and reproducibility of qualitative assessments are increased by the annotation of assessed values (e.g., this value is high because of the following reasons)". BSI §5.1 sets the target: "If a specific risk is assessed by two different employees of an organisation, the same result should be obtained." BSI's own frequency scale shows what a usable definition looks like. "Medium" is "once every 5 years to once a year", a range someone can check against the incident log.
That is the legitimate job. The grid puts a register in rough order, and people can discuss it. With defined scales and a written reason per rating, two assessors should land in the same cell.
L. A. Cox Jr. examined the mathematics in "What's Wrong with Risk Matrices?", published in Risk Analysis in 2008. The article is paywalled, so I quote only the abstract. It lists four limitations:
The second limitation is easy to reproduce. Take a common 5×5 scheme where the score is likelihood times impact, with log-spaced bands. The bands and both risks below are illustrative, made up for this example:
| Likelihood band | Impact band | Score | Illustrative expected annual loss | |
|---|---|---|---|---|
| Risk A: 11% a year, CHF 110,000 loss | 3 (10–30%) | 3 (100k–1M) | 9 | CHF 12,100 |
| Risk B: 9% a year, CHF 9.5M loss | 2 (1–10%) | 4 (1M–10M) | 8 | CHF 855,000 |
Risk B scores lower and carries about seventy times the expected loss. Each risk sits near a band boundary, and the bands are wide, so the rounding does the damage. NIST names the same mechanism in its cautionary note (Appendix J): risks "on the borderline between bins using the organization-defined binning scales, must ultimately be assigned to one bin. This determination could have a significant effect on the risk prioritization process."
The third limitation matters most at budget time. A matrix can tell you that A and B land in neighboring cells. It cannot tell you whether a CHF 50,000 control on A or on B buys more risk reduction. For that, NIST points to quantitative assessment, the kind that "most effectively supports cost-benefit analyses of alternative risk responses or courses of action."
A common scoring rule multiplies likelihood by impact and colors the grid by the product. That rule is a modeling decision. Neither NIST nor BSI requires it.
NIST's own example, Table I-2 in Appendix I, is a lookup table. Its corners:
| Likelihood | Impact Very Low | Impact Very High |
|---|---|---|
| Very High | Very Low | Very High |
| Very Low | Very Low | Low |
Very high likelihood with very low impact comes out Very Low. Very low likelihood with very high impact comes out Low. The table leans toward impact, which a symmetric product cannot do. Its High and Very High likelihood rows are identical, too.
BSI makes the same point from the other side. Its appendix on risk appetite calls the product "the simplest measure" and adds: "The management level decides which threshold values it classifies as "high"." It also allows an organization to be averse to frequent risks even when the damage is low, and says so plainly: "It is not always possible to provide rational reasons for attitudes towards risks."
Iso-risk curves address part of this. An iso-risk curve joins every point with the same product, so on a plot with continuous axes it is a hyperbola. Drawing the thresholds as curves, and each risk at its own coordinates, fixes one real problem: the cell boundary. Two risks just either side of a band edge sit next to each other instead of in two differently colored squares. Risks A and B would still land close to the same curve, because their inputs were rounded into bands before anyone drew anything; no plot recovers the seventyfold difference.
What the curves do not fix is everything upstream. The inputs are still ordinal judgments. Multiplying two ordinal numbers yields a number with no stated meaning. The curve still treats a risk rated 1 for likelihood and 10 for impact the same as one rated 10 and 1. That is risk neutrality, and your management may not be neutral about catastrophic losses. Cox's negatively correlated case remains too. I'd use a plot to see a register without rounding. I would not use its curves as the appetite statement.
Many registers carry two ratings per risk, one before treatment and one after it. Put side by side, they tell you whether treatment is expected to move anything. Keep the tense in mind. The residual rating is a forecast. It says what the risk will look like once a treatment is in place and working.
That forecast is what management signs. ISO/IEC 27001:2022 is paywalled, so I won't quote it. BSI's mapping table maps clause 6.1.3, "Information security risk treatment", to BSI Standard 200-3, among others. 200-3 §6 describes the step in words anyone can read:
"The residual risk must then be submitted to the management level for approval ("risk acceptance"). This documents in a traceable manner that the organisation is aware of the residual risk."
Management can only be aware of what the record shows. A drop from high to low on a before-and-after chart looks like progress. If the treatment behind it is still a plan, the drop is an intention. Before an acceptance, check three things per risk: which treatment the residual assumes, whether it is implemented, and who confirmed it.
A matrix, drawn in any tool, can be defended only by what sits beside it. This is what I would keep:
| Item | Why | Source |
|---|---|---|
| Scale definitions with examples per band | So two assessors land in the same cell | BSI 200-3 §5.1; NIST §2.3.2 |
| A one-line reason for each rating | Repeatability, and an answer when someone asks | NIST §2.3.2 |
| The combination rule (product, lookup table, other) | It decides the colors | NIST Table I-2; BSI appendix |
| The appetite threshold and who set it | BSI puts that decision on management | BSI 200-3 appendix |
| For each residual: the treatment it assumes and its status | The residual is a forecast | BSI 200-3 §6 |
| Acceptance: by whom, when, at which rating | The traceable record BSI describes | BSI 200-3 §6 |
devguard App 2.3.0 shipped assessment matrices "in three views: a heat map with counts per cell and an inspector beside it, a drift view putting initial and residual exposure side by side with the biggest movers, and a plot with iso-risk curves." Each risk carries an initial and a residual rating for probability and impact, each on a scale up to 10, and the score is their product.
The heat map rounds each rating to one of five bands per axis and shows how many risks sit in each cell. Select a cell and the inspector lists its risks with their treatment strategy. You can switch between initial, residual, or both. The drift view puts the two grids side by side, shows how many risks are high or above before treatment and how that number changes after it, and lists the biggest movers with their band before and after. The plot places each risk at its exact coordinates, using the residual rating where one exists, and draws the medium and high thresholds as dashed iso-risk curves. The asset matrix counts assets per confidentiality, integrity, and availability rating.
Three things the views do not do, each with a cost.
The appetite line is not yours. The plot counts risks "above appetite" at a score of 41 or higher, which is the product's high band, the same for every organization. It keeps the matrix counts consistent with the rest of the register. If management set a different threshold, read that panel as "high band," and keep your own threshold in the record.
A heat-map cell takes its color from the cell's band, and a risk near a boundary can disagree with it. A risk rated 9 for probability and 4 for impact scores 36, which is medium, but rounds into a cell tinted high. That is the borderline effect NIST warns about, reproduced by any grid. The plot and the movers list show each risk's own score, so check there before you argue about a color.
The drift view trusts the residual rating. It compares the two ratings as they stand on each risk today. It shows no history of how they changed, and it does not check that the treatment behind a residual exists or is implemented. A risk with no residual rating appears at its initial position in both grids. The treatment-action counts under the heat map are the nearest thing to a check, and they cover the whole register, not one risk.
The views make a register easier to read. What they show is what you entered, so the record in the table above still has to stand behind it.
Before your next management review, write down next to the matrix which combination rule you use and what your appetite threshold is, with the name of whoever decided each.
The assessment matrices shipped in devguard App 2.3.0.
Vadim leads engineering, the architecture, automation, and integrations that let compliance live. He's set on making a serious, audit-grade system genuinely easy to run.
Start free, bring your frameworks, and keep the evidence attached as the work ships. No setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships. No setup friction, no audit-week fire drill.