Who this is for: the IT manager, security lead or owner-operator who has been told to “set up a risk register” and wants one that is still being used a year from now. It assumes you have no register yet, or have one that nobody opens.
What a register is for, and what it is not
A risk register is a decision log with a score attached. Each entry records something that might go wrong, who is answerable for it, what has been decided to do about it, and when that decision will next be looked at. Everything else in the document exists to support those four things.
It is not an asset inventory, a vulnerability list, an incident log or a compliance checklist. Those are inputs. A vulnerability scanner output of 4,000 findings is not 4,000 risks; the register entry might be “internet-facing servers are patched late”, with the scanner output as evidence of how late.
The test of a good register is simple: if the person who owns the top entry were asked “what are you doing about this, and by when?”, the register should already contain the answer.
The fields that earn their place
Registers grow columns until nobody can fill them in. The set below is deliberately short. Every field answers a question someone will ask you in a board meeting, an audit or an insurer’s questionnaire.
| Field | What goes in it | Why it exists |
|---|---|---|
| ID | A stable identifier such as R-014 that is never reused | Lets minutes, tickets and audit evidence point at the same thing |
| Risk statement | One sentence: cause, event, consequence | Forces a risk that can be scored and treated, not a topic |
| Category | A short controlled list (access, vendor, data, availability, change, compliance) | Lets you filter and spot clusters |
| Asset or service affected | The system, process or data set | Ties the risk to something that has an owner and a business value |
| Risk owner | One named person with authority over the business outcome | Someone has to accept or fund the treatment |
| Likelihood and impact | The inherent scores, with a note on how they were reached | Makes the ranking reproducible |
| Existing controls | What is already in place and how you know it works | Separates inherent from residual risk |
| Treatment | Mitigate, transfer, avoid or accept, plus the specific action | The decision itself |
| Treatment owner and due date | The person doing the work and a calendar date | Turns intent into a commitment |
| Residual target | The score you expect after treatment | Defines what “done” means |
| Status | A defined list (see below) | Lets you report progress without reading every row |
| Last and next review | Dates | Stops entries ageing silently |
Notice what is missing: threat actor profiles, MITRE-style technique lists, long free-text narratives. Add them if a specific audience needs them. Do not add them because a template had the column.
Writing a risk so it can be scored
Most registers fail at the sentence, not the spreadsheet. Entries such as “Ransomware”, “Phishing” or “Cloud security” are topics. You cannot score a topic, because likelihood and impact depend on which system, which control weakness and which consequence you mean.
Use the cause, event, consequence pattern: because of a specific condition, a specific event could happen, resulting in a specific business consequence.
Take “Ransomware”. In a small finance-led organisation it might split into three different risks:
- Because remote access to the finance file server relies on passwords alone, stolen credentials could let an attacker encrypt or copy finance data, halting month-end close and exposing payroll records.
- Because backups are written to storage that the domain administrator account can also delete, an attacker with that account could destroy recovery copies as well as live data, turning an outage into a permanent loss.
- Because the accounting software is hosted by a single supplier with no documented exit route, a supplier-side ransomware event could stop invoicing for an unknown period.
Each of the three has a different owner, a different treatment and a different score. Scored together as “ransomware” they would produce one number that fits none of them.
A useful habit is to read the statement aloud and ask “what would I do differently on Monday if this score changed?” If the answer is nothing, the statement is too vague.
A complete entry
This is the shape of one finished record. The values are illustrative; use your own scale and definitions.
id: R-014
statement: Because remote access to the finance file server relies on passwords
alone, stolen credentials could let an attacker encrypt or copy
finance data, halting month-end close and exposing payroll records.
category: Access and identity
asset: Finance file server; VPN gateway
risk_owner: Finance Director
treatment_owner: IT Manager
inherent: likelihood 4 x impact 4 = 16 (CRITICAL)
scoring_note: Credentials for this VPN appeared in a previous supplier breach
notification; no second factor; finance data is not segmented.
existing_controls: VPN with password login; nightly backup (last restore test: none recorded)
treatment: MITIGATE - enforce MFA on VPN; restrict finance share to named group;
run and record a restore test
residual_target: likelihood 2 x impact 3 = 6 (MEDIUM)
due: 2026-12-15
status: In treatment
last_reviewed: 2026-10-09
next_review: 2027-01-09Two details matter more than they look. The scoring note records why the likelihood is 4, which is what lets a colleague challenge the number in a month without reopening the whole discussion. The restore test line is honest about a gap: “none recorded” is more useful than a comforting blank.
Owners: three different people
One column called “owner” hides three roles that are often different people.
- Risk owner. Answerable for the business outcome and entitled to accept or fund treatment. Usually a business or service owner, not the IT team. A risk owner who cannot spend money or accept consequences is a note-taker.
- Treatment owner. Does the work. Often in IT or security.
- Control owner. Operates a control the risk depends on, such as the person who runs joiner-mover-leaver processing.
When the register says “IT Manager” against every line, one of two things is true: the risks are all genuinely technical, or the business has not yet accepted that it owns the consequences. The second is more common, and it shows up at the first serious incident.
Status and review
Define a short, closed list of statuses and use nothing else. A workable set:
- Identified: captured, not yet scored.
- Assessed: scored, treatment not yet decided.
- Treatment planned: decision made, work not started.
- In treatment: work under way, with a date.
- Monitoring: treatment complete or risk accepted, being watched.
- Closed: the exposure no longer exists, for example the system was retired.
Set review cadence by band rather than a flat annual date. A reasonable starting rule is that critical and high entries are looked at every time the register is reviewed and at least quarterly, medium entries twice a year, and low entries once a year. Adjust to your size; the point is that the cadence is written down and someone is responsible for running it.
Also define out-of-cycle triggers. Re-score an entry when there is a security incident touching the same asset, a significant change to the system or supplier, a failed audit or access-review finding, a change in regulation or contractual obligation, or a control that has been found not to work. Triggers are what keep a register honest between scheduled reviews.
Where entries come from
A register fed only by a yearly workshop goes stale because workshops produce the risks people already know about. Wire in the sources that produce evidence:
- Incident and near-miss reviews, which show where controls failed in practice.
- Access review findings, such as privileged accounts nobody can justify.
- Vendor assessments, where the output should be a register entry rather than a PDF in a folder.
- Audit and insurer-questionnaire findings, which are often precisely the gaps you would rather have known about earlier.
- Change management, where a proposed change that introduces a new dependency is a new risk by definition.
- The restore and continuity tests you run, since a failed test is an entry on its own.
How registers fail
- Quantity as a goal. A register with 300 entries and one hour a quarter of review time is not being reviewed. Merge entries that share a cause and treatment; keep the register short enough to discuss.
- Scoring inflation and deflation. If everything is critical, nothing is. If a manager lowers scores before the board sees them, the register has stopped being evidence. Record who scored and why.
- Treatments with no date or owner. “Improve backup resilience” is a wish. “Run a documented restore of the finance server by 15 December” is a treatment.
- Treating the score instead of the risk. Moving a likelihood from 4 to 3 because it looks better is not treatment. Residual scores should fall only because a control changed. See risk treatment for how to record that properly.
- No closure. Entries that can never be closed or accepted accumulate until the register is unreadable.
- Confusing issues with risks. If it has already happened, it is an incident or a finding. The risk is that it happens again, or that something similar happens elsewhere.
- Hidden spreadsheets. A register that lives on one person’s laptop dies when they leave. Keep it in a shared, access-controlled place with version history.
What to do next
Start with ten entries, not a hundred: the ones you would be uncomfortable explaining to your board or insurer. Write them as cause, event and consequence, and score them using one written-out scale, such as the one in the risk scoring guide. You can enter them into the risk matrix tool to get a ranked list, a plot and a summary you can paste into your own register, remembering that its output is a working estimate and not an audit. Then pick the top entry, give it an owner and a date, and bring it to the next board report as a decision rather than a heat map.