Learn
The short answer
A risk register is a single list of the things that could go wrong, each scored for likelihood and impact, owned by a named person, and linked to the controls that reduce it. The two details that separate a register that survives an audit from one that does not are a second score after controls, and a named individual owner. Most registers record one score and assign risks to a team, which makes it impossible to show that anything improved or that anyone was accountable.
On this page
- What is a risk register?
- Why you need one
- What to include: the columns that matter
- Inherent and residual: the two scores
- How to create a risk register in seven steps
- Where risk registers go wrong
- Risk register vs risk assessment vs heat map
- How often to review it
- Do this in Venvera, with help
- Frequently asked questions
What is a risk register?
A risk register is the central record of the risks an organisation has identified, what each one could do, how likely it is, who owns it, what is being done about it, and where it stands now. It is the working document behind almost every information security and operational resilience framework, and it is usually the first artefact an auditor or supervisor asks to see. If you run Solvency II as well, the Pillar 2 governance side is covered in the Solvency II software buyer's guide. Supplier risk is one of the four sources feeding a register; the assessment side is covered in how to perform a third-party risk assessment.
It is not a document you write once. A register that has not changed in a year is telling you it is not being used.
Why you need one
Three reasons, in the order they usually bite.
Because a framework requires it. ISO 27001 expects a risk assessment and treatment process. DORA Article 6 requires an ICT risk management framework with identified risks. NIS2 Article 21(a) requires policies on risk analysis. SOC 2 covers risk assessment in the common criteria. All of them expect a maintained record rather than a one-off exercise.
Because decisions need a defensible basis. When someone asks why you spent budget on one control and not another, the register is the answer.
Because it is how the board discharges its duty. Under NIS2 the management body approves the risk-management measures and can be held liable. The register is the object they approve.
What to include: the columns that matter
| Component | What it holds | Example |
|---|---|---|
| Risk ID | A stable reference that does not change when the list is re-sorted | R-014 |
| Description | The event, its cause and its consequence in one sentence | Ransomware encrypts the core banking database, halting payment processing |
| Category | Grouping for reporting and trend analysis | Cybersecurity |
| Asset or process affected | What the risk attaches to | Core Banking Server |
| Owner | One named individual who can act | Head of Infrastructure |
| Likelihood | Scored on a defined scale | 3 of 5 |
| Impact | Scored on the same defined scale | 5 of 5 |
| Inherent score | Likelihood times impact before controls | 15 |
| Controls | The controls that reduce this risk, linked rather than described | Backup and restore testing, EDR, network segmentation |
| Residual score | The score after controls are considered | 6 |
| Treatment | Accept, treat, transfer or avoid | Treat |
| Action and due date | What is being done, by when | Extend immutable backups to the payments estate, 30 September |
| Status and last review | Where it stands and when it was last looked at | Open, reviewed 14 July |
Two of these carry most of the weight, and they are the two most often missing.
Inherent and residual: the two scores
An inherent score is the risk before your controls. A residual score is the risk after them. Registers that record only one score cannot answer the question every board and auditor eventually asks: what did our controls actually buy us?
Recording both also protects you in the other direction. If a control fails, the inherent score tells you immediately how exposed you now are, without re-running the assessment.
Use a defined scale and write the definitions down. A 5 by 5 likelihood and impact matrix giving a score of 1 to 25 is the common choice and it is sufficient. What matters is that "impact 4" means the same thing to everyone, which requires words rather than numbers: describe what a 4 looks like in money, in downtime, in customers affected and in regulatory consequence.
How to create a risk register in seven steps
1. Set the scope
Decide which legal entities, which assets and which obligations the register covers. A group running one register across five subsidiaries needs to know which risks are shared and which are local before anything is scored.
2. Agree the scale, in words
Define likelihood 1 to 5 and impact 1 to 5 with written descriptions before you score anything. Doing this after scoring means re-scoring everything.
3. Identify risks from four sources
Your asset inventory, your incident history, your supplier list and your regulatory obligations. Workshops alone produce a register of what people worried about that morning; those four sources produce one you can defend as systematic.
4. Score inherent risk honestly
Score as though your controls were not there. Teams find this uncomfortable and score the residual position by accident, which collapses the two columns into one.
5. Link each risk to the controls that reduce it
Link, rather than describe in prose. A linked control means that when the control's evidence goes stale, you can see which risks just got worse.
6. Score residual risk, with evidence
The residual score is a claim that your controls work. It should rest on evidence that they do, which is why the register and the control evidence belong in the same system.
7. Set appetite and route the exceptions
Decide the thresholds at which a risk is accepted, must be treated, or has to be escalated, and who makes each call. Without this the register is a list rather than a decision-making tool.
Want us to build it with you?
Book a 30 minute working session. Bring your asset list and your last incident. We will define your scale, populate your first fifteen risks, link them to controls and set your appetite thresholds, live on the call. You keep the register whether or not you become a customer.
Book a working sessionWhere risk registers go wrong
- Assigning risks to a team. "IT" is not an owner. A named individual with authority to act is.
- One score. Without inherent and residual, you cannot show improvement or exposure.
- A scale with no definitions. If nobody wrote down what impact 4 means, your scores are opinions in a numeric costume.
- Risks written as conditions. "Cybersecurity" is a category. "Ransomware encrypts the core banking database, halting payments" is a risk, because it names an event and a consequence.
- Controls described in prose instead of linked. Prose cannot tell you what to re-examine when a control fails.
- A register that only moves at audit time. The tell is that every last-review date is within the same fortnight, once a year.
- Treating the heat map as the deliverable. The map is a view. The register is the record.
Risk register vs risk assessment vs heat map
| Artefact | What it is | Relationship |
|---|---|---|
| Risk register | The maintained record of identified risks and their current position | The source of truth |
| Risk assessment | The process that identifies and scores risks | Produces and updates the register |
| Heat map | A likelihood by impact visualisation | A view generated from the register |
| Risk treatment plan | What you will do about the risks you are not accepting | The action column, expanded |
How often to review it
Quarterly for the register as a whole is a defensible default, with high scoring risks reviewed more often and a full re-assessment annually. Beyond the calendar, four events should trigger an update regardless of schedule: a significant incident, a new supplier supporting a critical function, a material change to your systems, and a change in your regulatory obligations.
Do this in Venvera, with help
Venvera holds the register with both scores, named owners, links from risks to the controls that mitigate them, appetite thresholds with automatic escalation, key risk indicators, and the heat map as a view rather than a separate spreadsheet. Because the controls and their evidence live in the same system, a residual score rests on evidence rather than assertion, and every framework you run reads the same register.
We will hold your hand through the first one
Most people do not need software as much as they need someone to sit with them for half an hour and get the first version right. Book a session and we will build your risk register together, on your data, and you keep it either way.
Book my risk register sessionFrequently asked questions
What is a risk register?
A maintained record of the risks an organisation has identified, each with a description, a category, a named owner, likelihood and impact scores, the controls that reduce it, a residual score, a treatment decision and a review date.
What should a risk register include?
At minimum: a stable risk ID, a description naming the event and consequence, the affected asset or process, a named individual owner, likelihood and impact on a defined scale, an inherent score, linked controls, a residual score, a treatment decision, an action with a due date, and the last review date.
How do you score risk in a register?
Score likelihood and impact on a defined scale, commonly 1 to 5 each, and multiply for a score of 1 to 25. Score twice: inherent, as though your controls were absent, and residual, after they are considered. Write down what each level on the scale means before scoring anything.
What is the difference between inherent and residual risk?
Inherent risk is the exposure before controls. Residual risk is what remains after them. Recording both is what lets you show the value of your controls and how exposed you become if one fails.
Who owns a risk in the register?
One named individual with the authority to act on it. Assigning risks to a department is the single most common weakness in a register, because a department cannot be asked for an update.
How often should a risk register be reviewed?
Quarterly for the register overall and annually for a full re-assessment is a common baseline. Update it out of cycle after a significant incident, a new critical supplier, a material system change, or a change in your obligations.
Can I build a risk register in Excel?
Yes, and many programmes start there. The limits appear when you need to link risks to control evidence, show that residual scores rest on something, and prove the register was maintained rather than assembled the week before an audit.
Which frameworks require a risk register?
ISO 27001 expects risk assessment and treatment, DORA Article 6 requires an ICT risk management framework, NIS2 Article 21(a) requires policies on risk analysis, and SOC 2 covers risk assessment in the common criteria. One register can serve all of them.
What is a risk appetite statement?
A written statement of how much risk the organisation is willing to accept, expressed as thresholds. It turns the register into a decision tool by fixing in advance which scores are accepted, which must be treated, and which are escalated.
