Risk register: keeping one that changes decisions

A risk register is the list of things that could go wrong, what you would do about each, and who is accountable. Kept well it is a short, live document that changes what the company does. Kept badly — and it usually is — it becomes a spreadsheet of generic worries, scored once, never revisited, produced only when a customer or auditor asks whether risks are managed.

The difference is almost entirely about wording. "Cyber security" is not a risk; it is a topic. "A ransomware incident encrypts our file store and we cannot restore because backups have never been tested" is a risk — it names the event, the cause and the consequence, and it implies exactly one action.

The columns that make a register useful

• Risk description as event, cause and consequence — a sentence you could hand to someone with no context.
• Category, kept to a handful: operational, financial, people, legal, technology, supplier.
• Likelihood and impact, on a scale you define in words rather than numbers alone. "Impact: high" means nothing until high is defined.
• Inherent score before mitigation, so the effect of what you do is visible.
• Existing controls — what already reduces this, honestly, including "none".
• Residual score after those controls. This is the number that should drive attention.
• Treatment decision: accept, reduce, transfer, avoid. Saying it explicitly prevents the default of quietly accepting everything.
• Action with an owner and a date, where the decision is to reduce.
• Status and last-reviewed date, so a stale entry looks stale.
• A trigger or early-warning signal where one exists — the thing that would tell you this is now happening.

Accept is a legitimate decision, and writing it down is the point. A register where every risk is marked for reduction and half the actions are overdue tells you nothing; one where six risks are consciously accepted and four have live actions is a document someone has actually thought about. Record who accepted it and when.

Running it

1. Populate it from what has actually gone wrong — to you, to companies like you, in your near misses. Generic risk lists produce generic registers.
2. Write each risk as event, cause, consequence. Reject anything that is a topic rather than a sentence.
3. Define the likelihood and impact scales in words before scoring anything, and keep them to three or four levels.
4. Score inherent, list controls, score residual. The gap is the argument for the controls you already pay for.
5. Decide treatment explicitly for every row, including accept.
6. Give every reduce decision one owner and one date. Actions owned by a team do not happen.
7. Review monthly at ten rows, quarterly at fifty — and always start with the overdue actions rather than the top of the list.
8. Add new risks when they appear and close old ones properly, with a note about why. A register that only grows becomes unreadable.
9. Take it seriously after near misses — those are free information about risks you had scored too low.

Keeping it short enough to read

A register of eighty rows is not more thorough than one of fifteen; it is a register nobody reads. Small companies do better with a tight list of the risks that would genuinely change decisions, reviewed properly, plus an appendix of accepted minor risks that gets looked at once a year. The test is simple: if the register has never caused anyone to do anything differently, it is documentation rather than management.

Ettex Records suits the register itself: custom tables with typed fields and no code, so likelihood, impact, scores, treatment and dates are real fields rather than free text; relations between tables so owners and categories are references; grid and kanban views with saved filters — overdue actions, residual score above your threshold, everything one person owns; formulas and rollups so residual score can be calculated rather than typed; revision history where every cell change is tracked and restorable, which matters when someone asks when a risk was re-scored; and row comments for the discussion. The risk policy and the scale definitions live in Ettex Docs, review dates in Ettex Calendar, and the continuity plan that several of these risks point to sits alongside.

Said plainly: Ettex has no risk module. There is no scoring engine, no heat map, no automatic escalation when a score crosses a threshold, no control library and no reminders when an action falls due. You get a structured, auditable table and the views you build on it. Enterprise risk management at scale is a different product category. Inside a process, the same risks appear in a risk control matrix paired with the control that addresses them.

How registers go stale

• Risks written as topics, which cannot be acted on or closed.
• Scales undefined, so scores are opinions expressed as numbers.
• Owners assigned without asking, who therefore do nothing.
• Actions with no date, or dates that pass unremarked.
• Only inherent scores recorded, so existing controls are invisible and unvalued.
• Everything marked for reduction, which is the same as no prioritisation.
• Reviewed annually the week before an audit, which is when it is least useful.
• Grows indefinitely because closing a risk feels like admitting it was never real.

A register lists risks; it does not test whether the controls against them work. Internal audit does that independently, and business impact analysis answers the different question of what it costs when a risk lands and how quickly you need to be back.

The register lists risks; two other exercises quantify and test them. A business impact analysis says what it costs when one lands and how fast you need to be back, and a disaster recovery plan covers the technical half of getting there.

A risk register works when each row is a sentence someone can act on, every treatment decision is explicit, and the review starts with what is overdue. If it has never changed a decision, it is not a register — it is a file.