The Risk Register: Fields That Matter and How to Keep It Alive

A risk register is the list of identified risks and what is being done about each one. Most organizations have one, and most of them are a spreadsheet nobody has opened since the last audit. The difference between a register that works and one that does not is a small number of design decisions.

The fields that matter

A risk statement that names cause, event and consequence. Not "ransomware" — that is a topic. Something closer to: unpatched internet-facing systems could be exploited, leading to ransomware deployment, resulting in loss of production for several days. A statement in that shape is assessable and actionable; a one-word entry is neither.

A business owner. The person accountable for the risk, which is the business leader whose function bears the consequence, not the security analyst who found it. This is the field organizations get wrong most often, and it is the one that determines whether anything happens. Security teams do not own business risk; they identify, assess and advise on it.

Inherent and residual ratings. Inherent risk is the level before controls; residual is what remains after them. Recording both shows what the controls are achieving and makes it visible when they are achieving little. The judgement that matters is whether residual risk sits within the organization's risk appetite — if it does, no further action is needed.

Likelihood and impact, on a defined scale. Define what each level means — in currency, in hours of downtime, in records exposed — because undefined scales produce ratings that are not comparable between assessors or over time.

Treatment and its status. Avoid, mitigate, transfer or accept, with the specific actions, an owner and a due date. A treatment without a date is an intention.

Review date, so entries are revisited rather than accumulating.

Where risks come from

A register built only from vulnerability scan output is a vulnerability list wearing a risk register's clothes. Draw from several sources: assessments and audits, incidents and near misses, threat intelligence about what is happening to organizations like yours, changes to the business, third-party assessments, and the exceptions granted when a control could not be applied.

That last source is worth singling out. Every accepted exception — a system that cannot be patched, an application that cannot support modern authentication — is a risk decision, and it belongs in the register with an owner and an expiry rather than in a separate document nobody reviews. The discipline is the same as under compensating controls.

Asset-driven methods such as OCTAVE are a good way to populate the strategic end of the register, since they start from what the business cannot operate without.

Qualitative and quantitative

Qualitative rating uses ordinal scales — low, medium, high — and is fast, consistent enough for prioritisation, and subjective. It is what most registers use.

Quantitative assessment attaches monetary values: single loss expectancy multiplied by annual rate of occurrence gives annualized loss expectancy, which can be compared against the cost of a control. It produces a defensible funding argument and requires data most organizations do not have, so estimates carry uncertainty that the precise-looking number hides.

The pragmatic approach is qualitative for the register generally, quantitative for the handful of risks where a real investment decision is being made.

How registers die

Predictably, and in the same few ways.

Too many entries. A register with four hundred rows is not read. Aggregate related technical findings into a small number of risk statements and keep the detail in the vulnerability management system where it belongs.

No owner, or the security team as owner of everything. Nothing moves, because the accountable person has no authority over the budget or the system.

Never reviewed. Entries go stale, treatments show as in progress for two years, and closed risks stay open. A regular review with owners present is the only thing that prevents it.

No connection to decisions. If the register does not inform budget, project approval or architecture, it is documentation for an auditor rather than a management tool — which is the governance failure described under COBIT, where the point of the artefact is that someone acts on it.

Report from it in terms leadership can use: movement in the top risks, treatments completed, exceptions overdue — the framing under security metrics, where a rising count of overdue treatments is precisely a key risk indicator.

Exam angles

Know the risk register as the record of identified risks with assessment, treatment, owner and review. Distinguish inherent risk (before controls) from residual risk (after controls), and know that residual risk is compared against risk appetite. Know the four treatments — avoid, mitigate, transfer, accept — and that the risk owner is a business leader rather than the security team. Compare qualitative rating with quantitative SLE, ARO and ALE calculation.