Download Mobile App
Create this template in Edworking
Get a ready-to-use project with tasks, workflow states and editable documents.
Use this templateAlready signed in? Your project opens automatically. Otherwise, sign up or log in to continue.
What Is a Risk Register?
A risk register records uncertain events that could affect a project, their possible consequences, the evidence behind the assessment, and who will respond. A risk may happen; an issue has already happened and needs active resolution.
Keep all material risks in the register. Use a filtered summary for the most urgent decisions rather than deleting risks to meet an arbitrary count.
What a Risk Register Must Contain
Start with the fields needed to make and review a decision. Define the project scope and rating scales at the top so readers can interpret each entry consistently.
Risk ID, Event and Consequence
Use a stable ID and explain the cause, what might happen, and the effect on a project objective. Keep supporting evidence and its date with the entry.
Likelihood, Impact and Rationale
Define the rating levels for this project, then explain the evidence for each assessment. A priority score is a sorting aid, not an exact probability or a substitute for judgment about a severe consequence.
Risk Owner and Action Owners
Name one accountable risk owner who monitors the exposure and coordinates decisions. Separate mitigation actions can have different owners and due dates.
Response, Trigger and Contingency
State what you will do now, what observable warning will prompt action, and the fallback if needed. Check that the fallback has the authority, time and resources it requires.
Status and Remaining Exposure
Distinguish an action being complete from a risk being resolved. Record the exposure that remains after a response, the evidence for any change, and who can accept it.
Last and Next Review
Record both dates and review sooner when a trigger fires or an assumption changes. Match the cadence to the risk and project pace rather than using one deadline for every row.
Step-by-Step: Build Your Risk Register
Build the first version during planning with the people closest to the work. Review it at project checkpoints and whenever new evidence changes an important risk.
Identify uncertain events
Review milestones, assumptions, dependencies and lessons from similar work. Write specific events and consequences; put problems that have already occurred into an issue log and link any remaining uncertainty.
Agree rating definitions
Use the organisation’s approved method or agree project-specific likelihood and impact descriptions. Record the time horizon and evidence. Do not present unsupported percentages as measured probabilities.
Prioritise decisions
Consider impact, likelihood, how soon action may be needed and the authority required. A low-likelihood event with a severe consequence may still need escalation. Keep lower-priority material risks visible with an appropriate review date.
Assign accountable owners
Name the risk owner and give each response task an action owner and due date. Confirm who can approve a contingency, accept exposure or change project scope.
Plan the response and fallback
Choose whether to avoid, reduce, share or accept the exposure. Write a concrete action, observable trigger and feasible contingency; document the rationale for acceptance rather than treating silence as a decision.
Review effectiveness
Check triggers, action progress and whether exposure actually changed. Completing mitigation is not enough to close the risk. Record the closure reason and date when the uncertainty ends; otherwise keep monitoring or obtain an authorised acceptance decision.
Share the useful view
Keep the register accessible to the people who need it. Summarise decision-worthy risks for sponsors, link response tasks and retain the history when a row closes or becomes an issue.
Worked Risk Register Example: Payment Integration
This fictional product-launch example extends one risk from identification through review. Copy the fields into a shared document or spreadsheet and adapt them; the names, dates and assessments are illustrative, not a customer result.
| Risk Register Item | Example Content |
|---|---|
| Project and assessment date | Product launch with checkout testing planned for 8 April. Assessment: 25 March, before the test window. |
| Risk ID and description | R-001. Because the payment provider has not confirmed integration-test access, access may arrive after 8 April, delaying checkout testing and the launch decision. |
| Current evidence | Provider API documentation received on 25 March; test-access date still unconfirmed. Mock checkout flow is complete, but this does not prove that real payment processing works. |
| Likelihood and impact | Likelihood: Medium — one external dependency remains unconfirmed. Impact: High — checkout testing is required for this launch. These labels use the team’s agreed project scale, not universal percentage thresholds. |
| Priority and accountable owner | Priority review before the test window. Risk owner: Alex Kumar, backend lead. Product lead approves any change to launch scope or date. |
| Mitigation and action owner | Alex requests written confirmation of test access by 1 April and books an integration-test slot. Record the provider’s response and test evidence in the linked task. |
| Warning trigger | No confirmed test-access date by 1 April, or an integration test fails on 8 April. Alex raises the issue with the product lead as soon as either condition is observed. |
| Contingency and authority | Product lead decides whether to move the checkout launch date. An alternative processor is an option only after feasibility, required approval and testing effort are checked; identifying a vendor is not a ready fallback. |
| Remaining exposure | Open: access is unconfirmed and end-to-end testing is incomplete. Reassess after access and testing evidence arrive; the completed mock flow does not remove the integration risk. |
| Status and review dates | Status: response in progress. Last review: 25 March. Next review: 1 April, or earlier if the provider changes its plan. |
| Closure or issue record | Close only with a recorded reason, such as completed required tests and no remaining uncertainty for this event. If the test date is missed, link the active issue and retain any remaining risk and decision history. |
Common Risk Register Mistakes
These patterns turn risk registers from protection into theater. Avoid them to keep your risk management credible.
Too many vague risks with no actionable mitigation
Keep all material risks, merge genuine duplicates and make vague entries specific. Use filters or a sponsor summary to focus attention; there is no universal maximum of 8–10 risks.
Risk register created once and never updated
Set a review cadence and trigger-based updates. A weekly check may fit an active launch, while other risks need a different rhythm. Record what changed and why.
Risks rated the same (all High/High)
Define the scale and explain each judgment. Do not down-rate a severe consequence simply to spread entries across a heat map; uncertainty in the evidence should be visible.
No assigned owner for each risk
Distributed ownership means no one owns it. Name a single person for every risk—they drive mitigation and updates.
Risks identified but no mitigation strategy
Record the chosen response and its rationale, including a conscious acceptance decision when appropriate. Acceptance needs the right authority, monitoring conditions and a review date.
Register hidden in email or one person's spreadsheet
Post the register in a shared, accessible doc. If the team can't find it, they can't act on it.
Closing a risk because a mitigation task is complete
Check whether exposure actually reduced or ended. Retain remaining risk, reassess it with evidence and record any authorised acceptance or closure decision.
Risk Review and Follow-Up Workflow
Risk management only works when it's a habit. Embed these practices into your project rhythm to keep risks visible and mitigation moving.
- Keep the register and supporting evidence in a shared location with appropriate access
- Review new warnings and decisions needed before reading through routine status updates
- Check whether completed response actions changed the exposure; keep unresolved uncertainty open
- Record new risks, owners and review dates when assumptions or dependencies change
- Link mitigation tasks to the risk ID and preserve decisions and closure reasons
- Escalate when exposure exceeds agreed tolerance or the response needs authority the owner does not have
Edworking lets you store your risk register in Docs, assign mitigation tasks immediately, and track progress without context-switching.
Key Takeaways
- A project risk register connects uncertainty, evidence, an owner and a response
- Keep all material risks; focus leadership attention through priorities and a filtered summary
- Separate the accountable risk owner from the owners of individual response actions
- Use review dates and observable triggers; completed mitigation does not automatically mean a closed risk
- Make the register accessible to the whole team in a shared doc—hidden registers don't prevent surprises
- Link mitigation tasks directly to the register so execution stays connected to planning
Frequently Asked Questions
There is no universal correct count. Keep risks that could materially affect your objectives, combine genuine duplicates and give each open risk an owner and review date. A long register may need workstream views or a sponsor summary, not deletion of valid risks.
Agree definitions for your project or use the organisation’s approved scale. Explain the likelihood evidence, possible effect and time horizon. The same two-week delay can be minor for one project and critical for another; generic probability percentages are not a substitute for evidence.
Consider avoiding, sharing or consciously accepting the exposure, as well as reducing it. Record who has authority to accept it, the rationale, any contingency and the next review trigger. Escalate a decision outside the owner’s authority.
Yes. Keep a dated reason and supporting evidence in the history, even if closed rows move out of the active view. Do not close a risk only because a mitigation task finished or nothing changed at the last meeting.
Both. The team identifies and updates risks asynchronously; leadership reviews and makes decisions about scope/timeline trade-offs during the sync. Risk management is everyone's job, but decision authority sits with leadership.
A risk describes uncertainty about a future event or effect. An issue is already happening or has happened and needs resolution. Link the issue to the original risk record and keep any remaining uncertainty visible.