Risk Register Template: Free Example, Fields, and How to Use It
The short version
A risk register is a living record of things that might go wrong, what you would do about each one, who owns it, and when you will look at it again. It tracks uncertain future events. Anything that has already happened belongs in an issue log, not here.
Copy this and start filling it in. Everything else on this page explains how to use these ten columns well.
| ID | Risk statement | Category | L | I | Score | Trigger | Owner | Response | Status | Next review |
|---|---|---|---|---|---|---|---|---|---|---|
| R-01 | If … then … | Open | YYYY-MM-DD | |||||||
| R-02 | If … then … | Open | YYYY-MM-DD |
Three rules make the difference between a register people use and a spreadsheet nobody opens: write every risk as an "if … then …" sentence, give every row one named owner, and put a date in the next-review column. A register without dates stops being a register within a month.
On this page: what it is · every field explained · worked example · scoring · writing the statement · register vs. RAID, RACI, and the rest · review lifecycle · cadence and closing · in AFFiNE · sources and method · FAQ
What a risk register is — and what it is not
NIST's glossary defines a risk register as "A repository of risk information including the data understood about risks over time," and, in a second entry, as "A central record of current risks, and related information, for a given scope or organization" (NIST CSRC glossary, risk register, accessed August 22, 2026). Both definitions carry the same weight: it is a record kept over time, not a one-off analysis.
That framing is also why the register is the artifact that gets rolled up. NIST IR 8286, Integrating Cybersecurity and Enterprise Risk Management (ERM) (October 2020), describes its own focus as "the use of risk registers to set out cybersecurity risk," explaining "the value of rolling up measures of risk usually addressed at lower system and organization levels to the broader enterprise level" (NIST IR 8286, accessed August 22, 2026). Registers are designed to aggregate; assessments are designed to conclude.
What belongs somewhere else
| What you actually have | Where it goes | What the register does with it |
|---|---|---|
| Something that already went wrong | issue log | nothing — move it out, or the register stops meaning "future" |
| A structured evaluation of exposure | risk assessment | material results become new register rows |
| A light, wide list of risks, assumptions, issues, dependencies | RAID log | the register is the deeper "R" of that log |
| Who executes, approves, is consulted, is informed | RACI matrix | supplies the owner name; RACI never holds risk state |
| What we learned after the fact | lessons learned | repeatable threats become rows in the next project's register |
The most common failure is quiet: teams let closed issues, action items, and general worries accumulate in the register until it is a hundred rows long and nobody can tell which five actually matter this week.
Every field, explained
| Field | What it answers | Rule that keeps it useful |
|---|---|---|
| ID | how do we refer to this row? | stable and short (R-01); never reuse a retired ID |
| Risk statement | what might happen, and so what? | one "if … then …" sentence, cause and consequence both named |
| Category | what kind of risk is this? | pick from a fixed list; free text makes filtering useless |
| Likelihood (L) | how probable is it? | use the scale defined in this register, not a personal hunch |
| Impact (I) | how bad if it happens? | rate the consequence, not the emotion |
| Score | how do we sort the list? | show the formula in the header, e.g. L × I |
| Trigger | what tells us it is happening? | an observable event with a threshold or a date |
| Owner | who is accountable? | exactly one named role; "the team" is not an owner |
| Response | what are we doing about it? | avoid, mitigate, transfer, or accept — plus the concrete action |
| Status | where does it stand? | a fixed vocabulary: Open, Mitigating, Accepted, Closed |
| Next review | when do we look again? | an ISO date; blank means the row is already stale |
Two of these carry more weight than the rest. Trigger is what turns a register from a worry list into an early-warning system: "the provider misses the September 25 checkpoint" is a trigger; "if things look bad" is not. Next review is what keeps the document alive; if you only add one column to an existing register today, add this one.
Worked example: ten tracked risks
The register below is a fictional editorial example. Northwind Labs, the Atlas 1.0 launch, the dates, and the roles were invented for this article. They do not represent AFFiNE customers, employees, or any real project, and none of the numbers came from a client engagement.
Project: Atlas 1.0 launch — Northwind Labs (fictional company) — register v1.2, data as of 2026-08-01 — maintained by: the project lead — scale: L and I from 1 to 3, Score = L × I.
| ID | Risk statement | Category | L | I | Score | Trigger | Owner | Response | Status | Next review |
|---|---|---|---|---|---|---|---|---|---|---|
| R-01 | If the payment provider's certification review slips past October 9, then launch billing cannot go live on November 6 | Vendor | 3 | 3 | 9 | Provider misses the September 25 checkpoint | Finance lead | Mitigate — weekly checkpoint; manual invoicing fallback for the first 30 days | Mitigating | 2026-09-01 |
| R-06 | If support headcount stays at two through launch week, then first-week responses exceed the 48-hour target | Operational | 3 | 3 | 9 | More than 30 open tickets on day 2 | Support lead | Mitigate — two temporary agents booked for launch week | Mitigating | 2026-09-01 |
| R-02 | If load testing shows p95 above 2 seconds at 500 concurrent users, then the launch date slips | Technical | 2 | 3 | 6 | p95 above 2 s in the October 12 test run | Engineering lead | Mitigate — profiling in week 6; five buffer days reserved | Open | 2026-09-08 |
| R-03 | If the only engineer certified on the cluster takes planned leave in November, then incident response degrades | Resourcing | 3 | 2 | 6 | Leave approved before October 1 | Engineering lead | Mitigate — cross-train a second engineer by October 23 | Mitigating | 2026-09-08 |
| R-09 | If the migration script fails on accounts above one million records, then rollback exceeds four hours | Technical | 2 | 3 | 6 | Dry run fails on the three largest fixtures | Engineering lead | Mitigate — dry-run the three largest datasets by October 9 | Mitigating | 2026-09-08 |
| R-04 | If the privacy review flags the retention period, then the analytics feature is cut from launch scope | Compliance | 2 | 2 | 4 | Legal comments returned after October 30 | Legal counsel | Accept — documented scope cut, feature ships later | Open | 2026-09-15 |
| R-08 | If a competitor ships a comparable feature before November 6, then the differentiation message weakens | Market | 2 | 2 | 4 | Competitor announcement observed | Marketing lead | Accept and monitor — alternative message drafted | Open | 2026-09-15 |
| R-07 | If the CDN contract is not renewed by October 2, then a service interruption becomes possible in November | Vendor | 1 | 3 | 3 | Renewal unsigned on October 2 | Finance lead | Transfer — renewed early on a 12-month term | Closed | closed 2026-08-14 |
| R-05 | If the translation vendor delivers late, then the Spanish landing page ships after launch | Vendor | 2 | 1 | 2 | No draft received by October 16 | Marketing lead | Accept — English-only at launch, Spanish two weeks later | Accepted | 2026-10-01 |
| R-10 | If the webinar platform caps at 500 attendees, then late registrations are turned away | Operational | 1 | 1 | 1 | Registrations pass 400 | Marketing lead | Accept — recording published within 24 hours | Accepted | 2026-10-01 |
Notice what the register is doing here. Two rows score 9 and both are reviewed weekly; four rows score 1 to 4 and are reviewed monthly or later. R-07 is closed but still visible, with its closing date — deleting closed rows destroys the only evidence that the risk was ever managed. And every response names an action with a date, not an intention.
Scoring: a 3 × 3 scale you can copy
| Likelihood | Meaning | Impact | Meaning |
|---|---|---|---|
| 1 | Unlikely — no known signal yet | 1 | Minor — absorbed within the plan |
| 2 | Possible — has happened on comparable work | 2 | Moderate — visible slip or extra cost |
| 3 | Likely — a signal is already present | 3 | Major — the committed date or scope changes |
Score = L × I. In the example register: 1–2 is low and reviewed quarterly, 3–4 is medium and reviewed monthly, 6–9 is high and reviewed weekly.
This is not the only valid scale, and it is not a standard. Many teams use 5 × 5; safety and cybersecurity contexts often use qualitative bands defined by their own frameworks. What matters is not which scale you pick but that the scale is written inside the register, so that a "3" means the same thing to everyone reading it six months from now. A number without a published definition is decoration.
Two related cautions. First, multiplying two subjective ratings does not produce an objective number; the score is a sorting device, not a measurement. Second, do not let the score alone decide attention: a score-3 risk with a trigger firing next week outranks a score-6 risk whose trigger is six months away.
Writing a risk statement that survives review
Most weak registers fail at the first column. Compare:
| Weak | Usable | |
|---|---|---|
| Statement | "Vendor delays" | "If the payment provider's certification review slips past October 9, then launch billing cannot go live on November 6" |
| Trigger | — | "Provider misses the September 25 checkpoint" |
| Response | "Follow up with vendor" | "Mitigate — weekly checkpoint with the provider; manual invoicing fallback covers the first 30 days" |
| Residual risk | not stated | "Manual invoicing is capped at roughly 200 accounts; above that the fallback fails" |
The left column cannot be reviewed. There is no threshold to check, no owner implied, and no way to tell next month whether things got better or worse. The right column can be reviewed in thirty seconds.
Residual risk is the field most often skipped and the one auditors ask about first: after your response is in place, what exposure remains? "Manual invoicing is capped at roughly 200 accounts" is an honest residual. "Risk mitigated" is not an answer.
Risk register vs. RAID log, risk assessment, RACI, issue log, lessons learned
| Artifact | Question it answers | Time orientation | What it must not do |
|---|---|---|---|
| Risk register | what might happen, who owns it, what will we do? | future, monitored continuously | hold items that already happened |
| RAID log | what risks, assumptions, issues, and dependencies are in play? | mixed, lighter per item | replace the depth of a register on the "R" |
| Risk assessment | how exposed are we, evaluated at a point in time? | a snapshot | become the ongoing monitoring record |
| RACI matrix | who executes, approves, is consulted, is informed? | per deliverable | carry likelihood, impact, or status |
| Issue log | what has already gone wrong, and who is fixing it? | present | hold hypothetical events |
| Lessons learned | what would we do differently next time? | retrospective | serve as active monitoring |
The clean handoffs are worth memorizing: an assessment produces register rows; a register row that materializes becomes an issue; a closed project's register feeds the lessons log; and the lessons log seeds the next project's register.
The review lifecycle
- Identify. Run a short session at kickoff and after every major scope change. Ask each function what it is worried about and write each answer as an "if … then …" sentence on the spot.
- Assess. Apply the published scale. Disagreement about a rating is useful information — record the higher rating and note why the two views differ.
- Assign. One named owner per row. If nobody will take a row, that is a decision to accept the risk, and it should be recorded as such rather than left blank.
- Respond. Choose avoid, mitigate, transfer, or accept, then write the concrete action and its date. "Monitor" is not a response; it is the absence of one.
- Monitor. Check triggers, not feelings. Every review touches the trigger column first.
- Close — or convert. A risk closes when its window passes or its trigger can no longer fire. If the trigger does fire, the row does not stay in the register: it becomes an issue, and the register records that it materialized.
This sequence sits comfortably alongside general risk-management practice. The UK Health and Safety Executive frames the same loop for workplace risk in five steps — "Identify hazards", "Assess the risks", "Control the risks", "Record your findings", "Review the controls" — and stresses that documentation is not the point: "Do not rely purely on paperwork as your main priority should be to control the risks in practice" (HSE, Managing risks and risk assessment at work, accessed August 22, 2026). The same warning applies to registers.
Review cadence and the closing checklist
| Score band | Review cadence | Who attends | What must change in the row |
|---|---|---|---|
| 6–9 (high) | weekly | owner + project lead | trigger status, response progress, next review date |
| 3–4 (medium) | monthly | owner | any change in likelihood or impact, with a reason |
| 1–2 (low) | quarterly | project lead | confirm the row is still relevant at all |
| Closed | at project close | project lead | closing date and closing reason recorded |
Before you close or archive a row
- The trigger can no longer fire, or its window has passed — state which.
- The closing date and a one-line reason are recorded.
- If the risk materialized, the corresponding issue is linked and the row is marked "materialized", not silently deleted.
- Residual risk is written down, even when it is "none".
- Anything worth repeating is copied into the lessons learned record before the project closes.
- The row stays visible in the archive; the register keeps its history.
Building and maintaining a risk register in AFFiNE
AFFiNE provides page documents with tables, an Edgeless canvas with shapes and connectors, real-time collaboration, and the ability to switch between page and canvas in the same workspace. The workflow below is entirely manual and uses only those capabilities:
- Create a page document and paste the ten-column table from the top of this article.
- Put the scale definition — what 1, 2, and 3 mean for likelihood and impact — directly above the table, so it travels with the register.
- Record the register version, the data-as-of date, and the maintaining role in the first two lines of the document.
- Keep one row per risk and sort by score; do not split high and low risks into separate documents.
- Use the Edgeless canvas for the identification session itself — one sticky per worry, then convert each into an "if … then …" row.
- Keep the page document and the canvas in the same workspace so whoever opens one can find the other.
- At each review, update the trigger column first, then status, then the next-review date.
Verified limits as of publication, so expectations stay accurate: AFFiNE does not score risks automatically, does not recalculate a score when likelihood or impact changes, does not send reminders when a review date passes, and does not import risks from a project-management or GRC system. We also do not publish a .xlsx or .docx risk-register download here, because we have not verified that such a file exists. Identification, scoring, and review remain human work — which is the point, since the value of a register comes from the judgment recorded in it.
Sources, method, and update criteria
Demand research — and one open gate. The US SERP for risk register template was re-read on August 22, 2026; the dominant intent combines copyable or downloadable templates with a field-level guide and a worked example, which is the format this page follows. The Ahrefs figures available to this draft (SV 1.3K, KD 4, TP 500) are a snapshot taken on August 21, 2026, not a same-day pull. They are reported here as a dated snapshot rather than as fresh data, and re-pulling US volume and difficulty on the publishing day remains an open item for review.
Why the example is fictional. Northwind Labs, the Atlas 1.0 launch, the dates, the thresholds, and the roles were written for this article. Publishing a real register would expose third-party information and would not be verifiable by readers. A complete fictional register is more useful than a real one with half its cells redacted. Nothing in this article reports customer outcomes, download counts, or certification status.
Product verification scope. Claims about AFFiNE are limited to what the official product pages describe: page documents with tables, an Edgeless canvas with shapes and connectors, real-time collaboration, and switching between the two modes. Automatic scoring, reminders, integrations, and export formats were not verified and are therefore not claimed.
Sources consulted (all accessed August 22, 2026):
- NIST Computer Security Resource Center, glossary entry for risk register — the two definitions quoted above.
- NIST, IR 8286, Integrating Cybersecurity and Enterprise Risk Management (ERM), October 2020 — registers as the artifact that rolls up.
- UK Health and Safety Executive, Managing risks and risk assessment at work — the five-step loop and the warning about paperwork.
- W3C Web Accessibility Initiative, Complex Images — two-part text alternatives, which is why every figure here is paired with a table.
- W3C, WCAG 2.1 — success criterion 1.4.1, why score bands are labeled and not only colored.
When this page will be updated. If search intent shifts, if NIST or HSE revise the referenced guidance, or if the AFFiNE capabilities named here change, we will update the text and correct the date. This is AFFiNE editorial content: we have a commercial interest in the product mentioned, which is why product claims are deliberately limited to what we could verify.
FAQ
What is a risk register template?
It is a reusable table for tracking uncertain future events: an ID, a risk statement written as "if … then …", a category, likelihood and impact ratings, a score, a trigger, one named owner, a response, a status, and a next-review date. The template is only the container; what makes it work is that every row has an owner and a date.
What columns should a risk register have?
At minimum: ID, risk statement, category, likelihood, impact, score, trigger, owner, response, status, and next review date. Add a residual-risk column as soon as your responses become concrete, because that is the field reviewers and auditors ask about first. Free-text categories should be replaced with a fixed list so the register can be filtered.
How do you score risks in a risk register?
Define a scale inside the register itself and apply it consistently. A 3 × 3 scale works well to start: likelihood 1–3 from unlikely to likely, impact 1–3 from minor to major, score = likelihood × impact. Many teams use 5 × 5 instead. The scale is a sorting device, not a measurement, so a low-scoring risk whose trigger fires next week still outranks a high-scoring one that is months away.
What is the difference between a risk register and a RAID log?
A RAID log is broader and lighter: it holds risks, assumptions, issues, and dependencies side by side, usually with a line or two each. A risk register goes deeper on risks alone, with scoring, triggers, responses, statuses, and review dates. Many teams run both, using the RAID log for weekly visibility and the register as the detailed record behind its "R" column.
How often should a risk register be reviewed?
By score band rather than by habit: high-scoring rows weekly with the owner and project lead, medium monthly with the owner, low quarterly to confirm they are still relevant. Every review updates the trigger column first, then status, then the next-review date. A row with a blank or past review date should be treated as stale until someone re-dates it.
