Royal Financial GroupRoyal Financial GroupDubai, UAE Request Funding
Management consultancyRoyal Financial Group

Building a risk register a board will actually use

Most registers are compliance artefacts nobody reads. A useful one names an owner, a trigger and a decision, quantifies impact in money, and gets reviewed on the same date every month.

Most organisations have a risk register. Very few have one that changes a decision. The document gets built for a funder, an auditor or a board pack, is admired once, and is then updated shortly before the next occasion on which somebody will ask to see it.

A register that has never caused anyone to do anything differently is not a risk management tool. It is a record that risk management was requested.

Why the usual register fails

The standard artefact fails in four predictable ways, and they compound.

  • No owner. Risks are assigned to departments rather than people. A department cannot be asked what it did last month.
  • No trigger. Likelihood and impact are scored on a colour scale with no statement of what observable event would tell you the risk is materialising.
  • No decision. Mitigations are described as postures — monitor, manage, review — rather than as actions with a cost and a date.
  • No money. Impact rated as high or medium cannot be compared against the cost of mitigating it, so nobody can decide whether mitigation is worth doing.

The four columns that matter

A register earns its place when every line answers four questions.

Who owns it

A named individual with the authority to act, not a function. The owner reports on their own risks at the review, in their own words.

What would tell us it is happening

A trigger is an observable, dated fact: a customer goes to tender, a supplier changes payment terms, a cover ratio passes a threshold, a permit slips beyond a date. Triggers convert a register from an opinion about the future into a monitoring instrument.

What it would cost

Impact in money, with the working shown. Ranges are fine; precision is not the point. What matters is that impact can be set against the cost of mitigation and a proportionate decision taken.

What we will do, and by when

A specific action, an owner, a date and a cost. If the decision is to accept the risk, that is a legitimate answer — recorded as a decision, with who took it and on what basis.

The review is the mechanism

The register is not the control. The meeting is. A useful cycle is short, monthly, on the same date, with the same attendees, and it covers three things only: which triggers have moved, which actions are late, and what has changed enough to be added or closed.

Closing risks matters as much as adding them. Registers that only grow are quickly ignored, because nobody can find the ten lines that matter among the hundred that do not.

Where it connects to the money

On a funded project the register should map directly to the assumptions underneath the financial model and the covenants in the facility. If a risk materialises and no line in the model moves, the risk was described too vaguely to be useful. If a covenant can be breached by an event that appears nowhere in the register, the register is incomplete.

Done properly, the two documents are the same analysis in different formats — and a board that reviews them together is a board that can see what a lender sees.

Have a transaction that needs testing before it moves?

Request Funding →