A risk register is the list of what could go wrong, how likely and how bad, who owns it, and what is being done. Done well it is the one document that turns security from a list of tasks into a set of decisions a manager can make. Done badly it is a spreadsheet nobody has opened since the last audit.
ISO/IEC 27001:2022 requires a documented risk assessment process (clause 6.1.2) and risk treatment (6.1.3), and the register is how most organisations evidence both. ISO 31000 describes the wider practice of risk management.
The columns, and why each is there
| Column | Purpose |
|---|---|
| ID, date raised | Gives every risk a stable reference and a history. |
| Risk title | One sentence a manager can read in a meeting. |
| Asset or process | What is at stake. |
| Threat and vulnerability | What could happen, and the weakness that lets it. |
| Existing controls | What already reduces the risk, so you do not double count. |
| Likelihood, impact, score | The assessment, on a scale you have defined. |
| Risk owner | A named person with the authority to act. Never a team. |
| Treatment and actions | What you will do, and by when. |
| Residual likelihood, impact, score | The risk after the treatment, which is what management accepts. |
| Status and evidence of closure | Whether it is done and how you can show it. |
| Last reviewed | When someone last looked at this row. |
A scoring scale to start from
Score likelihood and impact from 1 to 5 and multiply. The bands below are an example. Define your own criteria, write them down and apply them consistently, because ISO 27001 asks for consistent and comparable results.
| Score | Rating | Suggested response |
|---|---|---|
| 1 – 4 | Low | Accept, and review at the next cycle. |
| 5 – 9 | Medium | Treat within a planned period. |
| 10 – 15 | High | Treat with priority and a named deadline. |
| 16 – 25 | Critical | Escalate to senior management now. |
The four ways to treat a risk
- Mitigate: add or improve controls to reduce likelihood or impact.
- Accept: knowingly keep the risk, with the owner's and management's sign-off recorded.
- Transfer: share the risk, for example through insurance or a contract. Responsibility is not transferred, only some of the cost.
- Avoid: stop the activity that creates the risk.
A worked example
This is an illustration of the level of detail that works, not a real assessment.
| Field | Example |
|---|---|
| Risk | Customer data is exposed through an internet-facing admin portal without multi-factor authentication. |
| Likelihood × impact | 4 × 5 = 20, Critical. |
| Owner | Head of Engineering. |
| Treatment | Mitigate: enforce MFA, restrict the portal to the corporate network, review admin accounts. |
| Residual | 1 × 5 = 5, Medium. |
| Evidence of closure | A configuration export showing MFA enforced, and the firewall rule limiting access. |
Keeping it alive
- Review the high and critical rows monthly and the whole register at least once or twice a year.
- Add a risk whenever something changes: a new vendor, a new system, an incident, a new regulation.
- Close a risk only when there is evidence, not when the ticket is closed.
- Show the top risks to management regularly. A register that never reaches a decision-maker is not doing its job.