Risk Register: The Fields, the Owners, the Cadence That Keeps It Alive

The risk register is where risk management stops being a workshop and becomes a workload. It is the living list of what the organization has decided to worry about — each risk named, owned, scored, treated, and scheduled for another look. Many frameworks assume one exists; without upkeep, it can become an outdated spreadsheet that teams stop using. This guide is the register done properly: the fields that earn their place, the distinction between inherent and residual risk, the review cadence that keeps it alive, and the failure modes that turn registers into archives.

The fields that earn their place

A register row is a small contract. The risk, stated as an event with a cause and a consequence — “ransomware encrypts the file estate during peak season, halting order processing” — never a bare noun like “cyber.” The owner: one named person whose job includes this risk, at a level senior enough to fund its treatment. The category: hazard family or business line, so the register can be read by theme. Inherent likelihood and impact, scored on the scales your risk matrix uses. The controls that exist today, named concretely — not “IT security” but the specific segmentation, backup regime, and monitoring in operation. Residual likelihood and impact after those controls. The treatment decision — avoid, reduce, transfer, retain — and where treatment means action, the action, its owner, and its date. And the dates and status that keep the row honest: last reviewed, next review, and status with rationale if retired.

Inherent versus residual: the register’s central honesty

The gap between the two scores is a claim, and claims need evidence. Inherent risk is the exposure before controls — the flood plain, the unpatched estate, the single supplier. Residual risk is what remains once the controls you actually run are accounted for. Registers go dishonest in the residual column: controls listed that exist on paper, tests assumed that never ran, vendors trusted whose evidence expired last year. The working rule: a control may move a residual score only if you can point to its last test. Everything else is inherent risk wearing a costume — and the register’s job is precisely to refuse the costume, politely, in writing, forever.

The cadence that keeps it alive

Registers die of neglect between annual reviews. The rhythm that works: the full register reviewed on the same cycle as the risk assessment refresh — annually at minimum; the top tier — the highest residual risks — reviewed quarterly by the people who own them; and event-driven updates whenever the world moves: an incident, a near-miss, a new critical vendor, a facility change, a control that failed its test. Retire risks that no longer exist and say why; a register that only grows teaches its readers that it is a museum. Version it, date it, and make the changes visible — the diff between this year’s register and last year’s shows how the register changed.

Common failure modes

The noun register: rows that name topics (“supply chain,” “cyber,” “weather”) instead of events — untestable, unownable, unscoreable. The ownerless register: risks assigned to departments or committees, which is to say to no one. The static register: built for an audit, frozen until the next one, describing an organization that no longer exists. The padded register: two hundred rows no one reads, burying the eight that matter; a register’s credibility is set by its signal-to-noise, and pruning is a risk decision too. The orphan register: disconnected from plans, budgets, and the business impact analysis it should be arguing with — risks scored high that no plan treats and no budget funds are not being managed; they are being documented.

Frequently asked questions

What is a risk register?

The living record of an organization’s identified risks: each stated as an event, with an owner, inherent and residual scores, the controls in place, a treatment decision with actions and dates, and review dates. It is the operational output of the risk assessment and the agenda for risk governance.

What should a risk register contain?

At minimum: the risk stated as cause-event-consequence; a named owner; category; inherent likelihood and impact; the specific controls operating today; residual scores; the treatment decision and any actions with owners and dates; and last/next review dates.

How often should a risk register be reviewed?

Fully at least annually, aligned with the risk assessment refresh; the highest-residual risks quarterly; and immediately after incidents, near-misses, major changes, or failed control tests. A register reviewed only for audits describes the past, not the risk.

What is the difference between a risk register and a risk matrix?

The register is the record — every risk with its owner, controls, treatment, and dates. The matrix is the likelihood-against-impact scales used to score the risks, used to triage attention in a room. The register is where the work lives; the matrix is how the work gets discussed.

Updated 2026-10-31: citation-QC refresh — unsupported claims tightened to sources.

Updated Nov 1, 2026 — added the free risk register quick card, stays-alive pack, and register keeper downloads to this guide.