Risk Register for PMs
A product risk register that identifies, scores, and tracks mitigation plans for the key risks that could cause a feature or launch to miss its goals — from technical debt to user adoption. Free to copy, download, and use. No signup required.
# Risk Register **Product / Feature:** [Feature or initiative name] **PM Owner:** [Name] **Date Created:** [Date] **Last Reviewed:** [Date] **Review Cadence:** [ ] Weekly during build · [ ] Bi-weekly · [ ] Per sprint --- ## How to Score Risks Use a **Probability × Impact** score (1–5 each) to prioritize: | Score | Probability | Impact | |---|---|---| | 1 | Unlikely — < 10% chance | Trivial — cosmetic, no user impact | | 2 | Possible — 10–30% | Minor — affects < 5% of users | | 3 | Likely — 30–60% | Moderate — delays launch or affects core flow | | 4 | Very likely — 60–85% | Significant — affects majority of users or revenue | | 5 | Near-certain — > 85% | Critical — launch blocker or major incident | **Risk Score = Probability × Impact** - 1–6: Low (monitor) - 7–12: Medium (active mitigation needed) - 13–25: High (escalate, assign owner, weekly review) --- ## Risk Register | # | Risk | Category | Probability | Impact | Score | Status | Owner | Mitigation | Due | |---|---|---|---|---|---|---|---|---|---| | R-01 | [Risk description] | [Category] | [1–5] | [1–5] | [P×I] | Open | [Name] | [Mitigation plan] | [Date] | | R-02 | | | | | | | | | | | R-03 | | | | | | | | | | **Status options:** Open · In Mitigation · Mitigated · Accepted · Closed --- ## Risk Detail Entries ### R-01 — [Risk Title] **Risk:** [Full description of what could go wrong] **Category:** [ ] Technical · [ ] User Adoption · [ ] Dependencies · [ ] Compliance · [ ] Resource · [ ] Market **Probability:** [1–5] — [Justification] **Impact:** [1–5] — [Justification] **Risk Score:** [P × I] **Status:** Open / In Mitigation / Mitigated / Accepted **Root Cause:** > [Why might this happen? What's the underlying driver?] **Impact if it occurs:** > [What happens to users, launch timeline, or business metrics?] **Mitigation Plan:** - [ ] [Action 1 — e.g. "Run load test at 2× expected traffic before launch"] - [ ] [Action 2 — e.g. "Get legal sign-off on data retention policy by [date]"] - [ ] [Action 3] **Contingency (if mitigation fails):** > [What's the backup plan? e.g. "Roll back to v1 behind feature flag; communicate to customers within 2h"] **Owner:** [Name] **Review Date:** [Date] --- ### R-02 — [Risk Title] **Risk:** [Description] **Category:** [ ] Technical · [ ] User Adoption · [ ] Dependencies · [ ] Compliance · [ ] Resource · [ ] Market **Probability:** [1–5] **Impact:** [1–5] **Risk Score:** [P × I] **Status:** Open **Root Cause:** > [Why might this happen?] **Impact if it occurs:** > [What breaks or regresses?] **Mitigation Plan:** - [ ] [Action 1] - [ ] [Action 2] **Contingency:** > [Backup plan] **Owner:** [Name] **Review Date:** [Date] --- ## Common Risk Categories (Reference) ### Technical Risks - Third-party API instability or rate limits - Database migration complexity - Performance at scale (load, latency) - Security vulnerabilities in new endpoints - Mobile/browser compatibility edge cases ### User Adoption Risks - Feature too complex to discover without onboarding - Change disrupts existing workflow (negative habituation) - Feature solves a problem users don't know they have ### Dependency Risks - Another team's deliverable is on the critical path - External vendor contract or timeline - Design assets not finalized before engineering freeze ### Compliance / Legal Risks - Data residency or GDPR requirements - New endpoint exposes PII - Pricing or billing change requires terms update ### Resource Risks - Key engineer on leave during launch window - QA bandwidth insufficient for test coverage - PM bandwidth split across too many initiatives --- ## Risk Review Log | Date | Risks Reviewed | Changes Made | Next Review | |---|---|---|---| | [Date] | R-01, R-02 | [e.g. "R-01 score reduced after load test passed"] | [Date] |
How to use this Risk Register template
Create the register at project kickoff, not at launch minus one week
A risk register built the week before launch is a list of fires, not a plan. Build it when you write the PRD. Most risks are predictable from the technical design, the dependencies, and the user behavior — you don't need hindsight to spot them.
Score probability and impact separately
Teams tend to conflate high-impact with high-risk. A catastrophic edge case with 2% probability is a medium risk; a moderate issue that's near-certain is high risk. Scoring them separately forces you to think about both dimensions and avoids over-investing in low-probability scenarios.
Assign an owner to every risk above medium
Unowned risks don't get mitigated — they get re-discussed in the post-mortem. Every risk with a score ≥ 7 needs a named owner with a due date. The owner doesn't have to mitigate it alone, but they're accountable for tracking it.
Write the contingency before the mitigation
If mitigation fails, what do you do? Writing the contingency first removes optimism bias — it forces you to acknowledge the mitigation might not work. A launch without a rollback plan is a launch without a risk register.
Review at each sprint boundary, not just at launch
Risk scores change as the build progresses. A technical risk may be resolved after a successful spike; a dependency risk may increase when a partner slips. A stale register is worse than no register — it creates false confidence.
Want a Risk Register grounded in your actual customer data?
PMRead ingests your customer interviews, feedback, and Slack threads — and generates PRDs backed by real evidence, not guesses.
Frequently asked questions
How many risks should a typical feature have?
A small feature typically has 3–7 risks; a major launch or cross-team initiative typically has 10–20. If you have fewer than 3, you probably haven't thought hard enough. If you have more than 25, you may be logging implementation tasks as risks — risks are things that could cause the goal to fail, not a task list.
What's the difference between a risk and an issue?
A risk is something that might happen. An issue is something that has already happened and needs to be resolved. Move a risk to 'Closed' and open a separate issue tracker item when a risk materializes. The risk register is forward-looking; the issue tracker is reactive.
Should I include market or competitive risks?
Yes, if they're specific and actionable. 'A competitor might launch something similar' is too vague. 'Competitor X announced a competing feature at their conference last month — they may ship before our launch window' is a real risk with a probability and a mitigation (accelerate timeline, differentiate positioning).
When do I 'Accept' a risk vs. 'Mitigate' it?
Accept a risk when the cost of mitigation exceeds the expected cost of the risk occurring, or when mitigation is simply not feasible. Document the acceptance rationale — 'we accept R-04 because the affected segment is < 1% of users and the mitigation would require a 3-week delay' is a defensible position. 'We didn't get to it' is not.
Who should review the risk register besides the PM?
At minimum: the tech lead (for technical risk accuracy), the QA lead (for coverage gaps), and the stakeholder who owns launch go/no-go. For regulated industries or enterprise features, add legal/compliance. The register is only useful as a shared artifact — a PM's private spreadsheet doesn't create accountability.
Other free templates