A record needs a decision behind it
A risk register helps teams organize uncertainty. Its value depends on what changes because of the information inside it. If a risk is reviewed every month but never affects a plan, budget, or decision, it may be documented without being managed.
A useful entry describes a cause, a possible event, and a consequence. ‘Supplier delay’ is a label. ‘If the approval package is incomplete, fabrication may start late and push installation beyond the available access window’ gives the team something specific to examine.
Give the owner something to act on
Ownership should include the ability to monitor the risk and coordinate a response. Naming the project manager on every row creates a list of responsibilities without a working system.
For each significant risk, identify a trigger, a response, a due date, and the decision authority. For example, if approval is not received by a defined date, who decides whether to resequence the work? Make that agreement before the trigger occurs.
Use the meeting to test what has changed
Instead of reading each row aloud, ask which assumptions have weakened, which responses are overdue, and which exposures have become more important. Discuss links between risks when several depend on the same supplier, person, or approval.
Close the conversation with a small set of actions and explicit owners. The register should capture that reasoning so the next review can evaluate whether the response worked.