Download Mobile AppUse This Template in Edworking
Copy the template below, then paste it into Edworking Docs to start collaborating with your team.
Free plan includes unlimited docs, tasks, and team members.
What Is a Risk Register?
A risk register is a living document that captures all identified project risks, rates their probability and impact, and assigns mitigation owners. It turns invisible threats into managed action items.
The best risk registers are updated weekly, kept accessible to the team, and prioritized so leadership attention goes to the risks that matter most.
What a Risk Register Must Contain
An effective risk register includes only the fields that drive risk tracking and mitigation. Avoid analysis paralysis—capture what you need to act.
Risk ID and Description
A unique identifier and one or two sentences describing the threat clearly. Avoid vague language like 'resource issues'—be specific about what could go wrong.
Probability and Impact Rating
Two dimensions of risk severity: likelihood (High/Medium/Low) and impact if it occurs. Together they determine prioritization for mitigation effort.
Mitigation Owner
A single named person accountable for monitoring and mitigating this risk. Distributed ownership leads to risks being forgotten.
Mitigation Strategy
A one or two-sentence description of how the team will reduce probability or impact. This is the action plan—not vague hopes.
Status and Progress
Current status (Open/In Progress/Mitigated/Closed) and progress toward risk closure. Stale registers are ignored; live ones drive action.
Review Date
When the risk was last reviewed. Risks that haven't been touched in two weeks are signaling that nobody is actively managing them.
Step-by-Step: Build Your Risk Register
Follow this process during project planning and then review weekly. The initial build should take one hour for most projects.
Facilitate Risk Brainstorm
Gather the core team and spend 30 minutes identifying threats. Technical risks, resource risks, scope risks, external dependencies—list everything.
Rate Probability × Impact
For each risk, estimate likelihood (H/M/L) and impact (H/M/L). A high-impact, low-probability risk may still need mitigation. Use context from past projects.
Prioritize by Risk Score
Sort by combined severity. High/High risks get immediate mitigation plans. Medium/Medium risks get monitoring. Low risks get tracked but not actively managed.
Assign Mitigation Owners
For each risk, name a single owner responsible for watching it and executing the mitigation plan. No shared ownership.
Define Mitigation Strategies
For top risks, write the mitigation action—what will you do to reduce likelihood or impact? Avoid vague statements like 'monitor closely.'
Schedule Weekly Reviews
Set a recurring 15-minute risk review in your project sync. Review status, add new risks, and close mitigated ones.
Make It Visible
Post the register in a shared doc that the entire team can access. A risk register hidden in email attachments becomes invisible.
Template Example: Product Launch Project
Use this sample as your starting point. Adapt risk categories and owners based on your project context.
| Risk Register Item | Example Content |
|---|---|
| Risk ID | R-001 |
| Description | API integration with payment provider incomplete or delayed, blocking checkout testing |
| Probability | Medium |
| Impact | High |
| Risk Score | Medium/High — Priority mitigation |
| Mitigation Owner | Alex Kumar (Backend Lead) |
| Mitigation Strategy | Build checkout with mock payment flow by April 1. Schedule integration testing with provider by April 8. Have fallback payment processor identified. |
| Status | In Progress |
| Last Reviewed | March 25 — Mock flow complete, provider API docs received |
| Target Close Date | April 15 |
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
Limit registers to 8-10 risks max. Every risk needs a specific mitigation strategy and owner, not just 'we'll monitor this.'
Risk register created once and never updated
Review the register every week during your project sync. Risks change; registers that don't update become fiction.
Risks rated the same (all High/High)
Differentiate between true high-severity risks and low-probability concerns. If everything is a crisis, the register loses credibility and focus.
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
A risk with no action plan is just complaining. Every risk needs: What will you do? Who owns it? By when?
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.
Weekly Risk Review Workflow
Risk management only works when it's a habit. Embed these practices into your project rhythm to keep risks visible and mitigation moving.
- Store the risk register in a shared doc that all team members can see and update asynchronously
- Review top risks at the start of every weekly project sync—spend 15 minutes on this, not two hours
- Update status for all in-progress mitigations and close risks that have been resolved
- Add new risks that emerge during the week and immediately assign owners
- Link risk mitigation tasks to the register so actions are tracked and accountable
- Escalate any unmitigated high/high risks to leadership for support or scope decisions
Edworking lets you store your risk register in Docs, assign mitigation tasks immediately, and track progress without context-switching.
Key Takeaways
- A risk register captures threats, rates them by probability and impact, and assigns mitigation owners
- Limit registers to the top 8-10 risks—prioritize by severity so leadership attention goes to what matters
- Every risk needs a named mitigation owner and a specific action plan, not vague monitoring
- Review and update the register weekly; registers that go stale become invisible and useless
- 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
Use This Template in Edworking
Copy the template below, then paste it into Edworking Docs to start collaborating with your team.
Free plan includes unlimited docs, tasks, and team members.
Frequently Asked Questions
How many risks should be on a register?
For most projects, 5-10 identified risks is healthy. If you have 20+, you're either in crisis mode or the register is capturing noise instead of actual threats. Focus on risks that would materially impact schedule, budget, or scope.
How do we decide between High/Medium/Low ratings?
Probability: High = >60% chance, Medium = 30-60%, Low = <30%. Impact: High = project delay >2 weeks or major scope loss, Medium = 1-2 week delay, Low = minor rework. Base these on project history and evidence, not feelings.
What if a risk doesn't have a clear mitigation?
Then the mitigation strategy might be 'acceptance' — you've identified the risk, rated the impact, decided it's acceptable, and assigned someone to monitor it. Not all risks can be prevented; some must be managed.
Should we keep closed risks on the register?
Archive them to a separate section once closed. Keeping the active register clean makes it easier to spot current threats. But keeping a historical log of closed risks helps you refine estimates and patterns for future projects.
Who should review risks — just leadership or the whole team?
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.