A risk register can look complete while the project remains poorly prepared. The difference is usually action. Recording an uncertain event is a starting point; the team still needs to decide what it will do, who is responsible and when it will review the position.

Describe a risk so that someone can act

Explain the cause, the uncertain event and its possible effect on the project. “Supplier risk” is too vague. In a fictional equipment project, a clearer statement might identify a dependency on a single manufacturer, the possibility of a delayed shipment and the effect on installation dates.

Distinguish a risk from an issue. A risk concerns uncertainty. An event that has occurred and needs project-management consideration should be handled as an issue rather than left in the risk register as if it might still happen.

Agree a proportionate response

Consider probability and impact alongside the project’s risk appetite and available options. Reducing a threat may cost more than the likely consequence; accepting it may be reasonable if the decision is informed and within authority. Opportunities also deserve consideration.

Assign a risk owner who can monitor the risk and oversee its management. Where a separate person carries out a response action, be clear about that responsibility too. A name in the register should correspond to an understood task.

Review triggers and changing exposure

Identify what would tell the team that the risk is becoming more likely or that a response needs to begin. Review exposure when plans, suppliers or assumptions change.

The purpose is to improve decisions, not to produce the longest register. A short list of well-described risks with active owners is more useful than a large list nobody discusses. Bring material risks into planning and business-case decisions while there is still time to respond.