Risk Register with an Exposure Matrix: A Practical Guide
Almost every project has a risk register. Almost none of them get looked at between the kickoff meeting and the final autopsy. A register earns its keep when it prioritizes — when, out of twenty risks, it tells you which three matter this week — and that requires a scoring method that isn't just the writer's gut feeling.
What a risk is (and isn't)
A risk is an uncertain future event that, if it occurs, affects a project objective. It has three parts worth separating: cause (something already true), event (the uncertain part), and effect (the impact if it happens).
"Given that the integration vendor hasn't confirmed dates yet (cause), it's possible that the test environment won't be ready in February (event), which would cause a 3–4 week delay in UAT (effect)."
What's not a risk: something that's already happened (that's an issue), a task in the plan, or a generic worry ("the team might underperform"). If you can't assign it a probability under 100%, it's not a risk.
The register's columns
Not three, not thirty. These are the ones that get used:
| Column | Purpose |
|---|---|
| ID | Stable reference for minutes and tracking. |
| Description | Cause – event – effect, in one sentence. |
| Category | Technical, vendor, scope, resources, external… Useful for spotting patterns. |
| Probability | 1-to-5 scale (see below). |
| Impact | 1-to-5 scale, on the most-affected objective. |
| Exposure | Probability × Impact. The number that ranks the list. |
| Response | Avoid · Mitigate · Transfer · Accept. Plus the concrete action. |
| Owner | One person. Not "the team." |
| Status / review | Open / closed / materialized, and the date of the last review. |
Optional but useful on large projects: residual exposure (what's left after applying the response) and trigger (the observable signal that the risk is materializing).
How to score without fooling yourself
The problem with "high / medium / low probability" is that everyone interprets it differently. Fix the scales in advance, with numeric anchors:
| Level | Probability | Schedule impact (example) |
|---|---|---|
| 1 · Very low | < 10% | < 1 week |
| 2 · Low | 10–30% | 1–2 weeks |
| 3 · Medium | 30–50% | 2–4 weeks |
| 4 · High | 50–75% | 1–2 months |
| 5 · Very high | > 75% | > 2 months |
Impact is scored on whichever objective suffers most (schedule, cost, scope, or quality), and that objective is noted. A risk can be a 2 on cost and a 4 on schedule; you record the 4 and flag "schedule."
The rare-but-catastrophic trap. Probability 1, impact 5 → exposure 5. Probability 3, impact 2 → exposure 6. The multiplication says the second is "more important," and for weekly management it is. But the first one can sink the project. That's why the matrix doesn't replace judgment: any risk with impact 5 always gets reviewed, even if its exposure score is low.
The exposure matrix
It's a 5×5 grid of probability (vertical axis) against impact (horizontal axis). Each cell is the product, colored in bands:
- Red (exposure 15–25) — active response mandatory, named owner, reviewed at every committee. Rolls up to the portfolio report.
- Amber (8–12) — defined mitigation plan, biweekly review.
- Green (1–6) — accepted and watched; no action unless it moves up a band.
The matrix is drawn with risks placed in their cells. At a glance, you can see whether the project has a concentration problem (several dots in the upper right) or a long tail of green noise that's just a distraction.
The four responses
| Response | When | Example |
|---|---|---|
| Avoid | The risk is unacceptable and the cause can be eliminated. | Switch vendors before signing. |
| Mitigate | Reduce probability or impact to a tolerable level. | Early prototype of the critical integration. |
| Transfer | A third party is better positioned to absorb the impact. | Contractual penalty, insurance, fixed turnkey price. |
| Accept | The cost of responding exceeds the exposure. | Log it, define the trigger, and move on. |
"Accept" is a legitimate, explicit decision — not what happens by default when nobody does anything. An accepted risk has an owner and a trigger just like the others.
The contingency reserve
The sum of the cost exposures of open risks — their expected monetary value — is the basis for sizing the contingency reserve: budget within the baseline for known risks. When a risk materializes, it's funded from that reserve and documented; the project isn't re-baselined for something that was already anticipated. The management reserve, for unknowns, sits above the baseline and is controlled by the sponsor.
Why most registers are theater
They get filled in once, at kickoff, to satisfy the PMO's checklist, and never opened again. Signs that yours is dead:
- Every risk is still "open" with the same score as four months ago.
- None has been closed or materialized — statistically impossible on a real project.
- The owners don't know they're owners.
- The risk that actually sank the project wasn't on the list, or was scored green.
A living register gets reviewed at every status update: new risks, score changes, triggers fired, closures. It's fifteen minutes if the register lives alongside the rest of the project data — and a task that gets skipped if it lives in a separate spreadsheet someone has to go dig up.
In PMOvio, risk lives next to the project
A register per project with calculated exposure, a 5×5 matrix, and high risks rolling up automatically to the portfolio report. 15 days free, no card required.
See my portfolio →