Most risk register templates you find online have the opposite problem from the one you have. They are either a single row of vague headings — "Risk, Likelihood, Impact, Action" — that leaves out everything that makes a register useful, or a forty-column monster that no human being will ever keep current. This is neither. It is the smallest template that still holds everything a working register needs, with each column defined and a worked example you can copy today.
If you want the reasoning behind the design — why these fields and not others, and the habits that keep a register alive — that lives in the companion guide on how to build a risk register. This article is the artifact: the template itself.
The template
Here are the columns, in order, with what each one holds.
| Column | What it holds |
|---|---|
| ID | A short unique code (R-001, R-002...) so you can refer to a risk without retyping it. |
| Risk description | One sentence: cause → event → consequence. The most important field in the register. |
| Category | Strategic, operational, financial, compliance, IT/cyber, people, and so on. |
| Owner | One named person. Not a department, not "management." One name. |
| Inherent L / I | Likelihood and impact before controls, each rated 1–5. |
| Existing controls | What is already in place and operating against this risk. |
| Residual L / I | Likelihood and impact with current controls working, each rated 1–5. |
| Score | Residual likelihood × impact (1–25). Used for ranking. |
| Treatment | Strategy (avoid / reduce / transfer / accept) and the concrete next measure. |
| Deadline | The date the next measure is due. |
| Status | Open, in progress, done, or accepted. |
| Review date | When this risk is next due for an honest look. |
Twelve columns. That is the ceiling, not a target — if you can run without one of them, do. Every column you add is a tax on every update, and updates are what keep a register alive.
Every column, defined
A template is only as good as the shared understanding of what goes in each cell. The traps are always in the definitions.
ID. Trivial but useful. A stable code lets a treatment plan, a meeting note, or an email refer to "R-014" instead of re-describing the risk. Assign it once and never reuse it, even after a risk is closed.
Risk description. The field that carries the whole register. Write it as cause, event, and consequence in one sentence — "Because deployment lacks automated rollback, a faulty release may take the portal offline for hours, causing penalty payments and customer churn" — not as a noun like "IT risk." Everything downstream depends on knowing what the risk actually is. If you get only one field right, get this one.
Category. A single label so you can slice the register and spot clusters — five financial risks with no owner, say. Keep the category list short and fixed; a free-text category field becomes noise within a month.
Owner. One person who answers when the risk is discussed and feels a small, healthy discomfort when it is overdue. Shared ownership is no ownership. If you cannot name an owner, you have found a problem worth fixing before you fill the rest of the row.
Inherent and residual ratings. Two pairs of numbers on your defined 1–5 scales: the risk before controls and the risk with controls operating. The distinction matters enough to have its own guide — inherent vs. residual risk — but the short version is that the gap between them shows what your controls are worth. Anchor both to written scale definitions so that two people rating the same risk land within one level of each other; without definitions, the numbers are noise. See the 5×5 matrix guide for how to define those scales.
Existing controls. What already protects you against this risk, so the residual rating is defensible. A residual rating far below the inherent one is only credible if this cell explains why.
Score. Residual likelihood times residual impact. Use it to rank, never to manage blindly: a rare catastrophe and a frequent nuisance can share a score while demanding completely different responses. The score sorts the list; judgment runs it.
Treatment. The chosen strategy and the single concrete next measure — what, specifically, happens next. Avoid the wish-list trap ("improve security," "evaluate options"). A treatment must pass the checkability test: a named action with a definition of done.
Deadline and status. The date the next measure is due, and where it stands. Together these are what let the register tell you about slippage — the treatment postponed three times is a silent acceptance nobody actually decided.
Review date. When this risk is next due for an honest look. This is the field that keeps a register from freezing into wallpaper; when review dates pass unnoticed, the register is already dying.
A worked example
Three filled rows, to show the template in use. Ratings are on a 1–5 scale; the score is residual L × I.
R-001 — Because one client accounts for 35% of revenue, the loss of that client could halve annual income and force layoffs. Category: strategic. Owner: Maria (CEO). Inherent 3 / 5. Existing controls: quarterly relationship reviews. Residual 3 / 5. Score 15. Treatment: reduce — targeted sales push to grow the second tier of clients; first campaign scoped. Deadline: 30 Sep. Status: in progress. Review: Oct.
R-002 — Because backups have never been test-restored, a ransomware event could cause permanent data loss and days of downtime. Category: IT/cyber. Owner: Tomas (Head of IT). Inherent 4 / 5. Existing controls: nightly backups (untested). Residual 4 / 4. Score 16. Treatment: reduce — offline backup plus a documented restore test. Deadline: 15 Aug. Status: open. Review: Sep.
R-003 — Because the lead developer is the only person who understands the billing system, their departure could stall product changes for months. Category: people. Owner: Maria (CEO). Inherent 3 / 4. Existing controls: none. Residual 3 / 4. Score 12. Treatment: reduce — documentation sprint and a designated deputy. Deadline: 31 Oct. Status: open. Review: Nov.
Notice what the rows reveal at a glance: R-002 has almost no gap between its inherent and residual ratings, which flags a risk everyone "manages" but no control actually touches — exactly the kind of insight the two-rating format exists to surface.
Formatting rules that keep it usable
A few conventions separate a template that stays alive from one that rots.
Color the score, not the whole row. Apply the green / amber / red bands to the score cell only, so the matrix logic is visible without turning the sheet into a paint chart.
Sort by score, descending. The register's job is to put the worst risks at the top. A register sorted by ID or entry date buries the point.
One risk per row, always. The moment a cell contains "and also," you have two risks pretending to be one, and both will be rated wrong.
Keep a closed section, do not delete. When a risk is resolved or genuinely gone, move it to a "closed" area rather than deleting the row. The history of retired risks is part of your record — and auditors ask about it.
When the template outgrows the spreadsheet
This template works beautifully in a spreadsheet for a first pass, and there is no shame in starting there. The trouble arrives on schedule as the process matures: two versions of the file in circulation, no record of who changed a rating or why, review dates that pass unnoticed because nothing reminds anyone, and a quarterly report rebuilt by hand every time. Those are not failures of the template — they are the structural limits of a spreadsheet.
At that point the same template, in purpose-built software, gains the things a grid cannot provide: a change history on every field, automatic review reminders, a matrix that draws itself, and one URL that is always the current truth. EasyRisk.io is this template as a living tool rather than a file — free to start, with your existing register importable — so the move is a few minutes, not a migration.
Copy the columns, write your first ten risks as cause-event-consequence sentences, give each an owner and a date, and sort by score. That is a working risk register, and you can have it before the end of the day.
Frequently asked questions
What columns should a risk register template have? At minimum: an ID, a one-sentence risk description (cause, event, consequence), a category, an owner, inherent and residual likelihood and impact ratings, existing controls, a score, a treatment with the next concrete measure, a deadline, a status, and a review date. Around a dozen columns is the sweet spot — enough to be useful, few enough to keep current.
Is a spreadsheet good enough for a risk register? For a first pass and a handful of risks, yes. It stops working once several people need to update it, an auditor asks for the history of a rating, review dates start slipping unnoticed, or the quarterly report takes an evening to assemble. That is the point where the same template in dedicated software starts paying for itself.
How do you fill in a risk register? Write each risk as a cause-event-consequence sentence, assign one named owner, rate likelihood and impact before and after controls on a defined 1–5 scale, list the existing controls, choose a treatment strategy with one concrete next measure and a deadline, and set a review date. Then sort by score so the worst risks sit at the top.
How many risks should a register hold? For most organizations, twenty to sixty well-tended risks beat several hundred abandoned ones. If your register is growing past what anyone can maintain, consolidate duplicates, aggregate trivial items, and move minor risks to a watch list. A register nobody updates is worse than a short one that stays current.