Last updated: 2026-11-10
Measuring Risk: Exposure, Matrices and Their Limits
A list of risks isn't a plan. Analysis turns the list into an order of attention: which risks get action now, which need more information, and which only need watching. That means estimating, for each risk, how likely it is, how much it would matter, and how soon it could happen.finding risks is the first step
This page starts with the one quantity that does that job properly, risk exposure, then looks at the scored matrices most teams use instead and where they mislead. After that it covers how to estimate probability and impact without fooling yourself, how urgency changes priority, and what to write back into the register.
Risk Exposure FoundationalKnowledge that endures for decades — core principles
Boehm defines risk exposure as the probability of an unsatisfactory outcome multiplied by the loss if it occurs1:
RE = P(UO) × L(UO)
If a supplier has a 25% chance of delivering four weeks late, the exposure is 0.25 × 4 = 1 week. Exposure is an expected loss: across many risks like this one, the average cost is one week each.
Don't read that as "this risk will cost a week". For any single risk the outcome is either nothing or four weeks; it's never one week. That has a practical consequence. A one-week contingency covers the average of a portfolio of independent risks, but if this is the only large risk on the project and it happens, one week of slack won't absorb a four-week slip. Exposure is the right number for ranking risks and for sizing a reserve across many of them; it's the wrong number for deciding whether you could survive any one of them.like expected value, it hides the variance
Exposure also only compares like with like. Weeks of delay, pounds of cost, numbers of defects and harm to users are different units, and adding them needs an explicit conversion rate that somebody has to choose. In practice process risks convert easily into weeks and money, while product risks (a degraded user experience, a security weakness, an unfair outcome for some users) resist conversion. Our observation is that this asymmetry pushes registers towards over-weighting process risks simply because they're easier to put a number on. Record product impacts in their own terms rather than forcing a conversion that hides them.
Ordinal Scores Are Not Exposure FoundationalKnowledge that endures for decades — core principles
Most registers, including the template on this site, rate likelihood and impact on 1–5 scales and multiply them. That's a reasonable triage tool. It is not risk exposure, because the numbers are ranks, not quantities. On the scale used on the overview page, "1" for likelihood covers anything up to 10% and "5" covers anything above 90%; the gaps between the steps aren't equal, so multiplying them doesn't give a meaningful product.like Celsius: 20C is not twice as hot as 10C
The four risks below are scored on both systems. Impact is measured in working days of schedule delay.
| Risk | P | Loss (days) | L (1–5) | I (1–5) | Score L×I | RE (days) |
|---|---|---|---|---|---|---|
| A. Flaky CI slows merges for a sprint | 0.75 | 3 | 4 | 2 | 8 | 2.25 |
| B. Key developer leaves mid-project | 0.20 | 20 | 2 | 4 | 8 | 4.0 |
| C. Cloud region outage in launch week | 0.05 | 60 | 1 | 5 | 5 | 3.0 |
| D. Reporting requirements change after design | 0.50 | 5 | 3 | 3 | 9 | 2.5 |
By score, the order is D, then A and B tied, then C. By exposure, it's B, C, D, A: almost reversed. Risk C, the rare catastrophe, comes last on the scored ranking and second on exposure. Risk A, a frequent nuisance, ties for second by score and comes last by exposure. A team that followed the scores would spend its first effort on the reporting requirements and its last on the launch-week outage.
The Probability–Impact Matrix Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice
A probability–impact (PI) matrix collapses the two ratings into a coloured grid:
| Probability ↓ / Impact → | Low | Medium | High |
|---|---|---|---|
| High | Medium | High | Critical |
| Medium | Low | Medium | High |
| Low | Low | Low | Medium |
The usual rule is to act on Critical and High, monitor Medium, and watch Low. The matrix is quick and easy to explain to a client. Cox's analysis of risk matrices shows its limits: typical matrices can correctly and unambiguously compare only a small fraction of randomly chosen pairs of hazards; they give identical ratings to quantitatively very different risks ("range compression"); and they can assign a higher rating to a quantitatively smaller risk2. Risk C above is a case in point: low probability, high impact, rated Medium, and a larger exposure than two of the risks rated High.
Cox's conclusion is that matrices should be used with caution and with the embedded judgements explained. In practice that means using the matrix for a first sort and never as the final word on a risk that could end the project.use the matrix to sort, not to rank precisely
Qualitative First, Quantitative Where It Counts Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice
| Qualitative | Quantitative | |
|---|---|---|
| Ratings | Categories: High / Medium / Low, or 1–5 | Probabilities and losses in real units |
| Speed | Minutes per risk | Hours per risk |
| Precision | Coarse; ties are common | Fine enough to compare options |
| Use | Screening every risk | The top ten or so, and any risk with a catastrophic loss |
(1–5 or H/M/L)"] B --> C{"High score, or
catastrophic impact?"} C -->|yes| D["Quantitative estimate
P and loss in real units"] C -->|no| E["Watchlist"] D --> F["Rank by exposure;
plan responses"] style D fill:#FFC857
The second branch of the decision matters: a risk with a low score but a catastrophic impact goes to quantitative analysis anyway, because that's the case the matrix gets wrong.
Estimating Probability Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice
Three sources of probability estimates are common: team consensus, the Delphi technique (anonymous rounds with feedback; see Finding Risks), and historical data from earlier projects. Historical data is the most reliable when it exists and is relevant; consensus is the cheapest and the most prone to bias.
The main bias to guard against is overconfidence. Lichtenstein, Fischhoff and Phillips's review of calibration research found overconfidence to be the predominant pattern in people's probability judgements, and found it larger on harder tasks3. Software estimation is a hard task by that measure. Two habits help:
- Give ranges, not points. "Between 20% and 40%" is more useful than "30%", because the width of the range shows how much the team knows. Boehm makes the same point: the uncertainty in an estimate is itself a source of risk, and one of the best ways to reduce it is to buy information, for example by prototyping or benchmarking the uncertain part1.
- Think in distributions. DeMarco and Lister recommend uncertainty diagrams: plot the probability of each possible outcome (for instance, each possible delivery week) rather than naming a single date4.
An uncertainty diagram for a delivery date might look like this as a table (the figures are illustrative):
| Delivery week | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 |
|---|---|---|---|---|---|---|---|---|---|
| Probability | 2% | 5% | 10% | 18% | 22% | 18% | 12% | 8% | 5% |
| Cumulative | 2% | 7% | 17% | 35% | 57% | 75% | 87% | 95% | 100% |
If the plan says week 11, the cumulative row says that date has about a 7% chance of being met. That's a common pattern: the date that gets announced is the earliest plausible one, not the likely one. Committing to week 15 (75%) or 16 (87%) and treating the gap as a reserve is a risk response in its own right. Estimating Effort and Time covers the estimation techniques that produce the distribution.the median is the 50 percent percentile, not the mean
Estimating Impact Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice
| Dimension | Typical unit | Kind of risk it usually measures |
|---|---|---|
| Schedule | Days or weeks of delay; slip on the critical path | Process |
| Cost | Additional budget; effort in person-days | Process |
| Scope | Features cut or deferred | Process and product |
| Quality | Defects escaping; failed quality criteria (performance, availability, security) | Product |
| Harm | People affected; severity; reversibility | Product (see Product and Ethical Risk) |
A schedule impact only matters at its full size if the affected task is on the critical path. A two-week slip on a task with three weeks of float costs nothing; the same slip on the critical path delays delivery by two weeks. Critical Path Method and PERT shows how to tell the difference.
Data Quality Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice
An analysis is only as good as the estimates feeding it. Check that probability and impact figures are accurate (based on evidence rather than guessed), complete (all relevant factors considered) and from reliable sources (records, measurements, or people with direct experience).
| Red flag | Why it matters | What to do |
|---|---|---|
| A number with no stated basis | Nobody can check or update it | Record the assumption next to the number |
| A single person's estimate | One person's blind spots go straight into the ranking | Get a second, independent estimate |
| Historical data from a different kind of project | The base rate may not apply | Say why it's comparable, or discount it |
| Estimates that never change between reviews | The register has stopped being re-examined | Re-estimate at each milestone (see Keeping Risk Management Alive) |
Urgency Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice
Two risks with the same exposure aren't equally pressing if one could happen this sprint and the other in six months. Add a proximity rating:
- Imminent: could happen within the current sprint or iteration.
- Near-term: within the next one or two months.
- Long-term: in later phases.
Urgency also tells you when a response has to start, which is often earlier than when the risk could happen. If finding an alternative supplier takes six weeks, a supplier risk eight weeks out is effectively imminent. High-exposure, imminent risks form the core of the top-ten list that Boehm recommends reviewing at every project meeting1.lead time shifts the deadline backward
What Goes Back in the Register Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice
After analysis, each row of the risk register gains a probability rating, an impact rating, an exposure figure for the high-priority risks, a rank, an urgency flag, and a note on the basis of each estimate. Then sort the register into three groups:
| Group | Criteria | Next step |
|---|---|---|
| Immediate action | High exposure, or catastrophic impact, or imminent | Detailed response plan now: Responding to Risk |
| Further analysis | Medium priority, or estimates too uncertain to rank | Gather data: a spike, a prototype, an expert opinion |
| Watchlist | Low priority | Check at each review for changes |
Related Topics
- Risk Management & Mitigation: the overview, including the 1–5 scoring scale referred to above.
- Finding Risks: where the list being analysed comes from.
- Responding to Risk: what to do with the ranked list.
- Risk Burn-down Chart Template: tracking total exposure over time.
- Estimating Effort and Time: ranges, the cone of uncertainty, and calibration through retrospectives.
References
-
Boehm, B. W. (1991). Software risk management: Principles and practices. IEEE Software, 8(1), 32–41. https://doi.org/10.1109/52.62930 ↩↩↩
-
Cox, L. A., Jr. (2008). What's wrong with risk matrices? Risk Analysis, 28(2), 497–512. https://doi.org/10.1111/j.1539-6924.2008.01030.x ↩
-
Lichtenstein, S., Fischhoff, B., & Phillips, L. D. (1982). Calibration of probabilities: The state of the art to 1980. In D. Kahneman, P. Slovic, & A. Tversky (Eds.), Judgment under Uncertainty: Heuristics and Biases (pp. 306–334). Cambridge University Press. ↩
-
DeMarco, T., & Lister, T. (2003). Waltzing with Bears: Managing Risk on Software Projects. Dorset House. ↩
Graduate Attributes
Directly developed
- Critical Thinker: Readers compare risk rankings produced by ordinal scores against those derived from calculated exposure to identify misleading priorities.
Modelled on this page
- Subject Specialist: Technical distinctions are drawn between ordinal scores and quantitative exposure to clarify the mathematical validity of risk calculations.
- Reflective: The text examines the assumption that numerical rankings provide accurate prioritisation, revealing how easy-to-quantify process risks often overshadow product impacts.
University of Reading Graduate Attributes framework.