Risk Assessment & Mitigation Matrix Markdown Table Template
A risk matrix answers four questions about each thing that could derail a project: how likely is it, how bad would it be, what are we doing now to make it less likely or less damaging, and what will we do if it happens anyway. It usually sits in an engineering RFC, a launch readiness review, or a quarterly risk register, and the people reading it are approvers deciding whether to fund the mitigations, auditors checking that known risks have owners, and the on-call lead who will execute the contingency at 2 a.m.
Edit This Template
Edit cells, add rows, or sort — the Markdown updates livePaste cells from Excel or Google Sheets into the first header to replace the table · Tab / Enter / arrows move · Shift+F10 opens row & column actions
When to Use This Table
The two right-hand columns do different jobs, and blurring them is the most common way these tables fail. Mitigation is work you do in advance, on your own schedule, to reduce probability or impact; it has a cost and an owner. Contingency is the pre-agreed response once the risk has materialised; it needs a trigger (“p99 parse time above 5 s for 10 minutes”) so nobody debates whether to pull it. A row with a mitigation but no contingency is a bet that the mitigation works.
A useful matrix is built from risk statements specific enough to act on. “Security issues” cannot be mitigated; “an unescaped pipe in a code span splits the row and corrupts exported tables” can. Ratings come from a scale defined before anyone scores, and Overall Risk is looked up from that scale rather than chosen by feel, so two reviewers rating the same row land on the same answer.
What Goes in Each Column
| Column | Alignment | What to put here |
|---|---|---|
| Identified Risk Event | left :--- | Write each risk as cause, event, consequence: “Because previews load the whole file, a 100 MB CSV may exhaust tab memory, crashing the editor.” Left-aligned. One risk per row; if a sentence needs “and”, it is probably two risks with different owners. |
| Probability | center :---: | A label from your published scale (Low / Medium / High, or 1–5), centered. Anchor each label to something checkable, such as “happened at least once in the last four quarters” for High, so the rating reflects history rather than optimism. |
| Impact Severity | center :---: | Rate the consequence if the event occurs, ignoring how likely it is. Define the levels in business terms — users affected, data lost, hours of downtime, regulatory exposure — and keep them separate from probability, which is a different axis. |
| Overall Risk | center :---: | Derived, not chosen: look up Probability × Impact in a fixed matrix and bold the result so the column scans quickly (**HIGH**). Centered. Publish the lookup grid under the table so readers can verify any row in seconds. |
| Mitigation Strategy | left :--- | The preventive action, named concretely enough to estimate: a technique, tool, or design change (“stream parsing in a Web Worker in 1 MB chunks”). Add the owner and target date in brackets if the table has no separate columns for them. |
| Contingency Plan | left :--- | What you do once the risk has happened, ideally with its trigger condition. It should be executable by someone who did not write the RFC: a feature flag to flip, a fallback to enable, a limit to impose, a rollback to run. |
How to Fill It In
- 1Collect candidate risks from more than one source: a pre-mortem session (“it is six months from now and this failed — why?”), recent incident postmortems, the dependency list, and any threat model or compliance control set that applies.
- 2Rewrite each candidate as cause → event → consequence, then merge duplicates. Anything that is already happening is an issue, not a risk; move it to the issue tracker.
- 3Agree the Probability and Impact scales before scoring, and write them under the table. Have two or three people score independently, then discuss only the rows where they disagree; this avoids everyone anchoring on the first opinion voiced.
- 4Derive Overall Risk from the lookup grid and sort the table by it. The Markdown table sorter can do this, but note that a text sort on labels puts High before Low before Medium — sort on a numeric score column or reorder by hand.
- 5For every Medium-or-above row, confirm the mitigation has an owner and date and the contingency has a trigger. Set a review date for the whole register, and re-score after each mitigation lands.
Ready-to-Paste Variations
Scoring key (3×3 lookup grid)
Publish this directly under the main table so every Overall Risk value can be checked. It matches the ratings used in the template rows.
| Probability \ Impact | Low | Medium | High |
| :--- | :---: | :---: | :---: |
| **High** | Medium | High | **Critical** |
| **Medium** | Low | Medium | High |
| **Low** | Low | Low | Medium |Numeric 5×5 register with owners
For a standing risk register reviewed quarterly. Likelihood and impact are scored 1–5, the score is their product, and owner and review date make each row accountable.
| ID | Risk Event | L (1–5) | I (1–5) | Score | Owner | Next Review |
| :---: | :--- | :---: | :---: | ---: | :--- | :---: |
| `R-01` | Primary region outage takes the API offline | 2 | 5 | **10** | @platform-lead | 2026-01-15 |
| `R-02` | Key maintainer leaves; parser knowledge lost | 3 | 3 | 9 | @eng-manager | 2026-01-15 |
| `R-03` | Upstream library relicenses to non-commercial | 1 | 4 | 4 | @legal-liaison | 2026-04-15 |Inherent vs residual risk
Audit-style version showing the rating before and after mitigation, which is what reviewers need to judge whether the mitigation is worth its cost.
| Risk Event | Inherent Risk | Mitigation | Residual Risk | Status |
| :--- | :---: | :--- | :---: | :---: |
| Tab crash on very large CSV uploads | **HIGH** | Worker-based streaming parser | LOW | Done |
| Credential leak via client-side logs | **HIGH** | Redaction middleware and log review | MEDIUM | In progress |
| Search traffic loss after URL migration | MEDIUM | 301 map and canonical tags | LOW | Planned |Common Mistakes
Copying the mitigation into the contingency column, or leaving contingency as “monitor the situation”.
Ask “the mitigation failed and this is happening right now — what do we do?” The answer, with a trigger condition, is the contingency.
Multiplying ordinal scores as if they were measurements, so a near-certain trivial risk (5×1) ranks beside a coin-flip moderate one (2×3 is close).
Use the score only to sort, publish the lookup grid, and flag any row with maximum impact for explicit review regardless of its product score.
Rating almost every row High, which gives approvers no way to prioritise.
Calibrate against the scale definitions and force a ranking of the top five. If everything is High, the scale anchors are too loose.
Writing the register once for the RFC and never touching it again.
Give each row an owner and a review date, and re-score after each mitigation ships or a related incident occurs. A stale register is worse than none because it implies coverage.
Related Markdown Table Templates
Browse all 50 templatesProject Roadmap & Milestones
Quarterly roadmap tracking high-level initiatives, target milestones, delivery quarters, status indicators, and engineering leads.
Company & Team Quarterly OKRs Matrix
Objectives & Key Results governance table tracking strategic focus, baseline metrics, quarterly goals, confidence ratings, and leads.
Security Advisory & CVE Vulnerability Matrix
Track security advisories, CVE identifiers, CVSS v3 ratings, affected library versions, patched releases, and remediation guidance.
Risk Assessment & Mitigation Matrix: Frequently Asked Questions
What is the difference between a mitigation and a contingency plan?
A mitigation is proactive: it is done before the event to lower its probability or its impact. A contingency is reactive: it is the agreed response after the event occurs, usually with a trigger condition that starts it. Most risks above Low deserve both.
Should I use a 3×3 or a 5×5 risk matrix?
A 3×3 grid is enough for a design document or RFC with a dozen risks, and people score it consistently. A 5×5 grid gives more resolution for an organisation-wide register, but only if each of the five levels has a concrete definition; otherwise scorers cluster on 3.
What is the difference between a risk and an issue?
A risk is an uncertain future event; an issue is something already happening. When a risk materialises, it becomes an issue: you execute the contingency and track the work in your issue tracker, and the register row is updated or closed.
How do I calculate the Overall Risk column?
Combine Probability and Impact with a lookup grid like the scoring key variation above, or multiply numeric scores on a 1–5 scale. Either way, document the method under the table so that the column is reproducible and not a matter of opinion.