Project risk register: template and example from a recorded meeting

A risk may happen. An issue already has.

A project risk register lists uncertainties that may affect the outcome. It shows what to watch, what to do in advance and when to change the plan.

“The client delivered the materials three days late” is an existing issue. “If materials do not arrive by Wednesday, testing may run past Friday” is a future risk. They are related but call for different actions. This guide covers ordinary projects, not specialist registers for safety, audit or regulatory compliance.

How to build a register from a team discussion

1. Identify statements about uncertainty

   Look for “if,” “depends on,” “we don’t know yet” and “might not finish in time.” An assumption only belongs in the register if you can say which project outcome it affects.

2. Break the wording into three parts

   Cause or condition → possible event → consequence. Describe the dependency, for example, “approval depends on one person,” instead of “Alex is the risk.”

3. Agree on the assessment with the team

   Assess likelihood and impact separately. A small project can use qualitative levels with clear definitions. Keep subjective ratings distinct from calculated probabilities.

4. Assign someone to monitor it

   The owner tracks the trigger, gathers information and raises the issue. They need not resolve every cause alone and are not to blame if the event occurs.

5. Write down actions before and after the event

   Prevention reduces likelihood or impact. A fallback plan starts at a defined trigger. Name who performs both actions and what constraints apply.

6. Set the next review

   Check the entry at key milestones and when new facts emerge. Explain why you close it: a dependency was resolved, the event occurred or the relevant stage ended.

Test access for an integration

This excerpt is fictional. It does not prove the supplier will miss the deadline. Record the risk and confirm the request status separately.

There is deliberately no “70%” likelihood. The team lacks data to support that number. Update the assessment after the supplier replies. A dated trigger keeps the team from discussing the same worry on every call without new facts.

Update the register as the project changes

If access is granted, check that it works. An “access ready” email is not enough to close the dependency. If the risk materializes, link it to the issue and the fallback action. If likelihood decreases, record why.

Keep the register active. At meetings, focus on changed entries, approaching triggers and unassigned risks. Ask what you learned, how it affects the assessment and what to do next. If you decide on no additional measures, record the owner and conditions for review.

A basic register for your team

ID and date identified:
Project objective or stage:
If [condition], [event] may happen, causing [consequence].
Source: recording / timecode / supporting document:
Likelihood and basis:
Impact and basis:
Monitoring owner:
Preventive action, assignee and deadline:
Fallback trigger:
Fallback plan and who approves it:
Next review:
Status and reason for change:

• The condition can be checked.
• The wording preserves uncertainty.
• The trigger has a named owner.
• The entry has a next review date.