Risk Register Template
A risk register is only useful if it's actually filled in and actually re-read — a spreadsheet nobody opens after week one is worse than no register at all, because it creates the appearance of risk management without the substance. This page is a real, usable template: copy the CSV block below straight into a spreadsheet, or use the column definitions to build your own tracker in Jira, GitHub Projects, or a plain markdown table.
Columns, and what each one is actually for
| Column | Purpose |
|---|---|
| ID | A short stable identifier (R-01, R-02...) so a risk can be referenced from a commit message, a standup note, or another document without repeating its full description. |
| Description | One sentence stating what could go wrong, written as an event, not a vague worry — "the third-party payment API rate-limits us during a sales spike," not "payment stuff." |
| Likelihood (L) | 1–5, using the same scale as the scoring table on the main Risk Management page: 1 = Rare (≤10%) through 5 = Almost Certain (>90%). |
| Impact (I) | 1–5 on the same page's Impact scale: 1 = Negligible through 5 = Catastrophic. |
| Score (L×I) | Computed, not estimated directly — multiply the two numbers you just picked. This keeps the ranking mechanical and comparable across risks, rather than a second round of gut-feel. |
| Owner (Role) | A named role — "Backend Lead," "Release Manager" — not a team and, deliberately, not a person's name written directly into this table. A risk owned by "the backend team" is a risk nobody personally checks on. A risk owned by a person's name is a risk that silently loses its owner the day that person leaves, changes team, or goes on leave, and a register with stale names in it is exactly the kind of register that stops being read. See "Who actually holds each role" below for how the role-to-person mapping is kept current without touching this table. |
| Mitigation | The specific action that reduces likelihood or impact — see the Mitigation Strategies table on the main page for the standard categories (avoid, reduce, transfer, accept). |
| Status | Open / Mitigating / Closed / Accepted. A register where every row says "Open" months later is a register that stopped being read. |
| Last Reviewed | A date, updated every time the row is actually looked at again — not just when it's created. This is what makes a stale register visible at a glance: sort by this column. |
Copyable CSV template
Copy the block below (including the header row) and paste it into a spreadsheet — most spreadsheet applications will split it into columns automatically on paste, or use "Import" / "Text to Columns" with comma as the delimiter if not.
ID,Description,Likelihood,Impact,Score,Owner (Role),Mitigation,Status,Last Reviewed
R-01,Third-party payment API rate-limits us during a traffic spike,3,4,12,Backend Lead,Add local request queue with backoff; negotiate higher rate limit,Mitigating,2026-09-01
R-02,Key contractor leaves mid-sprint with undocumented deploy knowledge,2,4,8,Release Manager,Pair-write a runbook this sprint; cross-train one other engineer,Open,2026-09-01
R-03,Database migration script is not reversible if it fails partway,2,5,10,Backend Lead,Write and test a rollback script before running migration on production,Mitigating,2026-08-28
R-04,Test suite flakiness erodes trust in CI and gets ignored,4,2,8,QA Lead,Quarantine flaky tests into a separate non-blocking job; track flake rate,Open,2026-08-28
R-05,Chosen UI framework loses community support before project ends,1,3,3,Frontend Lead,Re-check framework health each term; no action needed yet,Accepted,2026-08-15
The five example rows above are filled in deliberately, not left blank, so you can see the difference between a well-written risk ("third-party payment API rate-limits us during a traffic spike") and a vague one before you start writing your own.
Who actually holds each role
Naming a role instead of a person in the register only works if something else, kept separate from the register, says who currently holds that role and who covers it when they can't. Without a deputy, "Backend Lead" quietly becomes a single point of failure with an extra layer of indirection — the same risk the register exists to catch, now hiding inside its own Owner column. Keep a small, separate roster like this one, updated the day a role changes hands rather than when someone next happens to notice:
Role,Current Person,Deputy,Last Updated
Backend Lead,A. Patel,R. Chen,2026-08-01
Release Manager,J. Osei,A. Patel,2026-08-01
QA Lead,J. Osei,R. Chen,2026-08-01
Frontend Lead,R. Chen,A. Patel,2026-08-01
Two consequences follow from splitting it this way. First, staff churn becomes a one-line edit to the roster rather than a hunt-and-replace across every open risk that person happened to own — the register itself never needs touching when someone leaves. Second, the Deputy column answers the question a named-person-only register can't: if the Backend Lead is on leave the week a payment-API risk fires, the roster says immediately who picks it up, rather than leaving it to whoever notices the owner isn't responding.
Using it well
- Review it on a cadence, not just when something breaks. A weekly five-minute pass — has anything's likelihood or impact changed, has anything been mitigated, is anything new — is what separates a living register from a document you wrote once for a rubric.
- Sort by Score, then by Last Reviewed. The risks that most need attention are the highest-scoring ones that haven't been looked at recently.
- Close risks explicitly. Moving a row to Closed with a one-line note on how it resolved is itself useful project evidence — it shows you tracked something through to an outcome, not just identified it and moved on.
- Update the roster the moment a role changes hands, not at the next scheduled review. A stale roster is worse than a stale register, since every open risk's owner is only as current as the roster says it is — treat "someone changed team" as an event that triggers an immediate roster edit, not a task queued for later.
See the Risk Burn-down Chart template for how to turn this register's Score column into a single trend line showing total risk exposure falling over time.