A risk register is a single list of the risks that could affect an organisation's objectives, with, for each risk, a clear description, an owner, a rating, the controls in place, the planned response and a review date. A good register is short enough to be read and specific enough to act on. Below are the fields that matter, a worked example, and how to keep the register alive rather than filled in once a year.
The fields that make a register useful
| Field | What to write | Common mistake |
|---|---|---|
| ID | A unique reference, such as OPS-04 | None |
| Risk title | A short name | Vague titles such as "IT" |
| Description | Cause, event and consequence | Describing only the cause or only the impact |
| Category | Strategic, operational, financial, compliance, technology, people, reputational | Too many categories |
| Owner | One named person | A department or committee |
| Inherent rating | Likelihood and impact before controls | Skipping it, so nobody knows what controls are worth |
| Existing controls | What already reduces the risk | Listing controls that do not actually operate |
| Residual rating | Likelihood and impact with current controls | Rating optimistically |
| Appetite | Whether the residual risk is within appetite | No appetite defined |
| Response | Reduce, transfer, avoid or accept | "Monitor" as a default response |
| Actions | Specific action, owner and due date | Actions with no date |
| Review date | When the risk will next be reviewed | The same date for every risk |
| Trend | Rising, stable or falling since last review | Missing, so the board cannot see change |
A worked example
This example is fictional and simplified for illustration.
| Field | Entry |
|---|---|
| ID | TECH-02 |
| Risk title | Ransomware attack on core systems |
| Description | Because staff can open email attachments and several servers are unpatched (cause), ransomware could encrypt our order and finance systems (event), stopping orders for up to two weeks and exposing customer data (consequence) |
| Category | Technology |
| Owner | Head of IT |
| Inherent rating | Likelihood 4, impact 5: very high |
| Existing controls | Antivirus on all laptops; nightly backups; annual phishing training |
| Residual rating | Likelihood 3, impact 4: high |
| Appetite | Above appetite: the board's appetite for data loss is low |
| Response | Reduce |
| Actions | Patch all servers (IT Operations Manager, 31 October); test restore from backup (Head of IT, 30 November); quarterly phishing simulation (HR, from January) |
| Review date | Monthly until within appetite |
| Trend | Rising, due to sector incidents |
How to create a risk register
- Start from objectives. Ask what could stop the organisation achieving each one.
- Collect risks in workshops, not by email. People describe risks better in conversation.
- Write each risk as cause, event and consequence.
- Agree a rating scale with definitions for each score, so ratings mean the same thing across teams.
- Assign one owner to each risk.
- Keep it short. An enterprise register with more than about 30 risks is usually mixing enterprise and operational detail. Keep the detail in departmental registers.
Ownership and review
A register is only as good as its review cycle.
- Owners update their risks on an agreed schedule, monthly for high risks.
- The risk lead challenges ratings, especially where residual ratings drop without a new control.
- Leadership reviews the whole register quarterly, focusing on risks above appetite and overdue actions.
- New or escalating risks are raised immediately, not held for the next meeting.
- Closed risks are archived with a reason, not deleted.
Signs your register has stopped working: ratings never change, actions are always overdue, or nobody can remember the last time it changed a decision.
Related reading
- Enterprise risk management subject guide: frameworks, registers, appetite, assessment and the course
- Risk register practice pack: a worked register entry with defined scales
- How to build an enterprise risk management framework
- Risk appetite vs risk tolerance: a practical business example
- Risk assessment matrices: how to use them and where they fall short
Designing and maintaining a register is one of the core skills in practical enterprise risk management training such as our Enterprise Risk Management course.
The bottom line
Use the fields above, write every risk as cause, event and consequence, give it one owner, and review it on a rhythm. A register that changes decisions is worth more than a long one that nobody reads.