A risk register is a living list of uncertain events that could affect objectives, plus probability, impact, response strategy, and owner. Update it regularly so risks drive action, not only reporting.
- Write risks as cause-event-effect statements.
- Assign one owner per risk response action.
- Review top risks on a fixed cadence, not only when issues appear.
Capture risks with usable detail
Describe each risk clearly: if a condition occurs, then a specific project impact may happen. Include trigger indicators where possible.
Use a consistent probability and impact scale so ranking stays comparable across teams and time periods.
Link scoring to response
High-priority risks need explicit response strategies: avoid, mitigate, transfer, or accept. Accepted risks still need contingency triggers.
Archive closed risks with notes. Historical risk patterns help future planning and estimation.
- Include due date for each response action
- Track residual risk after mitigation
- Escalate risk trends, not just single entries
Risk register entry for vendor API instability
Portal messaging depends on a third-party notification API.
- Log risk: if API uptime falls below SLA, patient notifications can be delayed, affecting pilot trust.
- Score probability as medium and impact as high based on past incidents.
- Assign owner to integration lead and create mitigation: fallback queue plus alert thresholds.
- Set trigger: two outage events in 30 days prompts executive escalation.
Common mistakes
- Listing generic risks with no project-specific cause or impact.
- Keeping risks without owners or due dates.
- Confusing active issues with future uncertainty.
- Scoring risks once and never updating them.
Try one
Why include trigger indicators in a risk register?
Triggers tell the team when to activate response actions before impact grows.
Sources
- Project Management Institute: What is project management?PMI overview of core project management concepts and practices.