How to build a risk register that earns its keep

Most risk registers are born in a spreadsheet and die there. They are created to satisfy a requirement, reviewed once, and then quietly ignored until the next audit forces a hurried update. A register in that state is worse than none - it creates a false sense of assurance.

A useful register has structure and ownership. Each risk has a clear owner, a rating that reflects the client's context, a treatment plan, and a review cadence. It is tied to the controls and frameworks the organisation is measured against, so movement in the register means something.

Drift tracking is what keeps it alive. When the environment changes - new sources, new systems, changed maturity - the register should reflect it, and someone should be prompted to review.

Generating the register as part of the onboarding pack, connected to the same intake that drives the rest of the documentation, gives it a fighting chance of staying relevant.