The risk register¶
What you'll be able to do in this chapter
- Explain what a risk register is and how it differs from a risk matrix.
- List the fields a useful register holds and why each is there.
- Run the register as a living, governed record rather than a one-off document.
Where the analysis lives after the workshops end¶
The scenario work produced decisions that need to remain visible and maintained. The risk register is the record of every identified risk, what is being done about it, who owns it, and where it now stands. Without it, a risk assessment is an event that happened once and is forgotten by the next quarter. With it, risk management becomes a continuous practice the organisation can actually run and the board can actually see.
Register and matrix are not the same thing¶
People conflate the register and the matrix, so be clear: the matrix is a visualisation (a grid showing where risks sit by severity and likelihood); the register is the record (the structured list of the risks themselves, with all their detail and history). The matrix is one view onto the register's data. You can plot the register on the matrix, but the matrix cannot hold ownership, treatment, dates or status. The register is the source of truth; the matrix is a picture of part of it.
What the register holds¶
A useful register has a row per risk and, at minimum, these fields, each earning its place:
| Field | Why it is there |
|---|---|
| Identifier and description | So the risk can be referred to and discussed unambiguously |
| Business value and supporting assets affected | Ties the risk to what matters and where it lands (Chapter 4.2) |
| Risk source and scenario | Records who and how (Chapters 4.3 to 4.4) |
| Inherent level | The evaluated level with the socle in place, before bespoke treatment |
| Treatment decision and action plan | Reduce, share, avoid or retain, with the linked controls (Chapter 4.6) |
| Owner | The named single accountable owner, so the risk is not orphaned |
| Residual level | Where the risk sits after treatment, and the basis for acceptance |
| Acceptance | Who accepted the residual risk, and when |
| Status and review date | Whether treatment is on track, and when the risk is next revisited |
The fields are not bureaucracy. Each one answers a question a director or auditor may ask.
Without assigned owners, a register cannot drive remediation; without review dates, it becomes obsolete; and without residual risk levels, it fails to support informed acceptance decisions.
Each field has a purpose: keeping the risk visible, owned and actionable.
A living, governed record¶
The register only works if it is maintained. Risks change as treatment progresses, as the business changes, and as the threat landscape shifts (a new ATT&CK technique, a new supplier, a lost OEM contract). So the register is reviewed on a cycle by the security committee (Lesson 2.4) and summarised for the board (Lesson 2.5), and it is the natural input to the next macro pass (Lesson 4.1.B). A register that is written once and not reviewed no longer provides an effective current view of risk. But, a register that is reviewed every quarter is the active part of the risk programme.
Application: draft three register rows¶
On paper, draft register rows for three Scaldimet risks (including the line-halt risk), filling every field above. Then check two things: that each row has a named owner and a review date, and that the residual level follows from the treatment you recorded in Chapter 4.6. Draft your rows before opening the model.
Model answer (open after you've drafted yours)
Three rows (fields: scenario · inherent · treatment · owner · residual · acceptance · status · review):
-
Line halt via OT compromise · inherent Critical (S4×L4) · reduce: segment Beta OT, monitor contractor access, compensating controls on the unpatchable SCADA · owner: the Beta operations director · residual High (S4×L2) · accepted by the risk owner and the management body (severity 4) · status: in progress · review: quarterly.
-
Customer design data disclosed · inherent Critical · reduce: access control and monitoring on the PLM and file shares, encryption at rest · owner: the Alpha IT manager · residual Medium · accepted by the risk owner · status: in progress · review: quarterly.
-
Compliance not demonstrable at audit · inherent Major · reduce: maintain the evidence store and SoA, run internal audit (3.6) · owner: the CISO · residual Low · accepted by the risk owner · status: on track · review: before each audit cycle.
Both checks pass: every row has an accountable owner (a role, so it survives the holder leaving) and a review date, and each residual follows from the treatment in 4.6: segmentation drops likelihood, so the line-halt residual falls from Critical to High. A row with no owner or no date is where a risk goes unowned and stalls; the register exists to prevent that.
Key takeaway
The risk register is the living record of every identified risk: its scenario, inherent level, treatment, owner, residual level, acceptance, status and review date. It is distinct from the matrix, which is only a visualisation of part of the register's data; the register is the source of truth. Each field answers a question a director or auditor will ask, and the register must be maintained and governed (reviewed by the committee, summarised to the board, feeding the next macro pass), or it becomes a dead document. A register without owners and review dates is where risks are forgotten.