A risk register is one list of the situations that could damage your business, each written in plain language, each assigned to a named owner, and each carrying a date when it was last looked at. If you are working out how to write a risk register, the short version is this: describe each risk as a specific situation rather than a topic, record what you already do about it, put one person’s name against it, and keep the list short enough that someone will read the whole thing in a sitting.
This article is general information about documentation and recordkeeping. It is not legal, compliance or security advice. Which obligations, frameworks and reporting duties apply to any given business varies by organization, industry and jurisdiction, and those questions belong with a qualified professional who knows your circumstances.
What a risk register is, and what it is not
A risk register is a working document. It lives in a spreadsheet or a simple table, it gets edited when something changes, and its value comes from being current rather than from being thorough.
It is not a report, and it is not a task list. A task list tells you what someone is doing this month. A register tells you what you have decided to live with, what you have decided to act on, and who made each of those calls. Those are different documents, and mixing them is the fastest way to make the register unreadable.
It is also not a judgment about anyone else. When a supplier or a contractor shows up in your register, the entry describes your exposure and your own arrangements, not a verdict on that company.
The columns in a risk register
Start with a narrow set of columns and resist adding more. Every extra column is a field somebody has to fill in on every row forever.
| Column | What goes in it | Why it earns a column |
|---|---|---|
| ID | A short code that never changes | Lets you reference an entry in meeting notes without retyping it |
| Risk description | One or two plain sentences, cause and effect | This is the whole document; everything else is metadata |
| Area | The part of the business it sits in | Lets you filter without a second register |
| Owner | One person, by name | Gives the entry somebody to speak to it |
| What we already do | The arrangements in place today | Separates the current position from the wish list |
| Decision | Act, transfer, avoid, or accept with a reason | Records the call that was made and by whom |
| Next action and holder | One line, or blank | Keeps the register pointing at something real |
| Last reviewed | A date | Shows the document is alive |
Eight columns is enough for most businesses. If you want severity, add a single plain rating of high, medium or low rather than a numeric scale, and write down what each word means on a definitions tab before anyone uses it. A rating nobody can reproduce is worse than no rating, because it looks precise.
How to write a risk register entry in plain language
The entry is the part people get wrong. Most first drafts contain topics, and a topic cannot be owned, acted on or closed.
Write each one as a situation and a consequence. The pattern is “If this happens, then that follows.” Compare these two attempts at the same row:
- Topic, not a risk: “Third-party risk.”
- A situation: “Our client files are processed by an outside bookkeeping firm, and we hold no current record of who at that firm can open them, so if their staff changes we would not know.”
The second one is longer and it is better, because it tells you what the next action is. It also tells a reader in a year’s time what you were worried about, which the first one does not.
Three habits make entries usable:
- Name the thing. Say which supplier, which record set, which process. Vague entries survive review because nobody can disagree with them.
- Write the consequence in business terms. Work interrupted, records unavailable, a commitment you could not meet, a question you could not answer. Avoid technical shorthand that only one person on the team reads the same way.
- Keep it to three sentences. If an entry needs a page, it is probably several entries, or it belongs in a separate document that the entry points to.
Where the first entries come from
You do not need a workshop to start. Pull from four places: things that have already gone wrong, the dependencies you could not replace quickly, the commitments you have signed up to in writing, and the parts of the business that only one person understands. Twenty to thirty entries from those four sources is a solid first pass.
For a business with outside suppliers, the register and the vendor records feed each other. A gap you find while reviewing a supplier becomes a register entry; a register entry about concentration tells you which supplier file to open next.
Who owns each entry
One name per entry, and a person rather than a team. A team owner means no owner, because nobody reads a row addressed to everybody.
The owner’s job is narrow and worth stating out loud so nobody declines it by accident. The owner says whether the description is still accurate, whether the arrangements described are still in place, and whether the decision still stands. The owner does not have to do the technical work, and does not have to be senior.
Two practical rules keep ownership honest. First, tell people they own a row, in writing, and let them edit it. Second, when someone leaves or changes role, reassigning their rows is part of the handover, not a cleanup job for later. An orphaned row stays unexamined for as long as the register exists.
How to write a risk register review schedule you can keep
A register that was written once and never touched tells a reader that the process is on paper only. The cure is a small, boring rhythm.
Hold a short review on a fixed cadence, quarterly for most small and mid-sized businesses. In the review, each owner does three things: confirms or corrects the description, confirms or changes the decision, and sets the next review date. Minutes of a page are plenty.
Log what changed, including when nothing changed. A line reading “reviewed, no change, March” is evidence of attention. Keep the previous version rather than overwriting it, because the trail of edits is the part that shows the document is in use.
Trigger an off-cycle look at an entry on four events: the business takes on work of a kind it has not done before, a supplier relationship starts or ends, the owner of an entry changes, or something actually goes wrong. Those four catch most of the cases where a register quietly goes out of date.
Keeping the register to a readable length
Length is a feature, not an accident. A register nobody finishes is a register nobody uses, and the usual failure is growth rather than neglect.
Three disciplines keep it in bounds. Retire entries that no longer apply, moving them to a closed tab with the date and reason rather than deleting them. Merge entries that describe the same situation from two angles. And push detail down: an entry can point to a vendor file, a data inventory row or a decision memo instead of absorbing it.
If you are over about fifty live entries and the business is small, the register has usually started collecting tasks. Pull those out into whatever you already use to track work, and leave the register doing the one job it does well, which is holding the decisions.
A risk register does not make anything safer on its own. What it does is make the next conversation possible, whether that is with a customer asking how you handle their records, a supplier you are taking on, or your own team six months from now trying to remember why a decision was made. Build the first version in an afternoon, keep it short, and review it on a rhythm you can hold. For a plain list of the documents that usually sit alongside it, including the vendor and data records that feed it, see the Trust Center Document Checklist page on this site.