A project risk register records uncertain events that could affect objectives and what the team plans to do about them. It helps turn vague worries into clear, owned actions. A useful register focuses on risks that matter to the project, keeps ratings consistent, and is reviewed as conditions change.
Risk versus issue
A risk is an uncertain event or condition that could affect the project if it occurs. An issue is something that has already happened and needs action. For example, 'the supplier may miss the delivery date' is a risk; 'the supplier missed the delivery date yesterday' is an issue.
Keep the two separate because their response is different: risks need preventive or contingency planning, while issues need immediate resolution and ownership.
What to include in a risk register
A basic register should identify the risk, its cause and potential effect, likelihood, impact, owner, planned response, due date and current status. Some teams also track triggers, residual risk and escalation needs.
Write risks as cause-event-effect statements where possible. This helps the team think clearly about what could happen and why it matters.
Risk ID | Risk statement | Likelihood | Impact | Owner | Response | Status
R1 | Supplier delay may postpone testing | Medium | High | Project lead | Confirm dates; identify backup | OpenRate probability and impact
Teams often use qualitative scales such as Low, Medium and High, or numerical scores. The important part is to define what each level means. A 'High' rating should be applied consistently rather than being a guess that changes from person to person.
If you multiply probability and impact scores, document the scale and how score bands map to action. A simple number can help prioritize, but it does not make an uncertain estimate mathematically precise.
Choose a response and assign an owner
A response should say what will actually be done, who will do it, and by when. Common response strategies include avoiding the risk by changing the plan, mitigating likelihood or impact, transferring certain consequences through an appropriate agreement or insurance, or accepting the risk with a contingency plan.
For an event-planning project, a risk could be that an outdoor venue becomes unavailable due to weather. The team might reserve an indoor backup and set a decision date for switching locations. The response is concrete and has an owner.
- Avoid: change the plan to remove the exposure.
- Mitigate: lower the likelihood or impact.
- Transfer or share: allocate part of the consequence through an appropriate arrangement.
- Accept: monitor the risk and prepare a contingency if needed.
Review and maintain the register
Review the highest-priority risks at regular project checkpoints and whenever an important assumption changes. Close risks that are no longer relevant, add new ones, update owners and record whether the planned response has been completed.
Avoid filling the register with every imaginable event. Focus on material uncertainties that could affect scope, schedule, cost, quality, safety or stakeholder acceptance. The register should support decisions, not become paperwork for its own sake.
- Assign an owner to each active risk.
- Set a clear next action and due date.
- Review triggers and changing assumptions.
- Move realized risks into the issue log when appropriate.
- Record decisions and lessons for future projects.
Understanding the concept is the first step.
Explore related resources or learn about subject-focused tutoring designed to help you understand the material.