A risk register is a living document that catalogs identified project risks, scores their likelihood and impact, assigns owners, and tracks mitigation actions. It is the operational backbone of project risk management — the place where abstract worries become concrete plans.

Risk Register Template: Track, Score, and Mitigate Project Risks

Every project has risks. The difference between projects that survive surprises and those that derail is whether the team saw the risk coming and prepared for it. A risk register forces that preparation into a structured, reviewable format.

Risk Register Structure

A practical risk register needs these columns:

Column	Purpose	Example
Risk ID	Unique identifier	R-007
Description	What could happen	”Key backend developer leaves mid-project”
Category	Risk domain	Resource, Technical, External, Schedule
Probability	Likelihood (1-5)	3 — Possible
Impact	Severity if it occurs (1-5)	4 — Major
Risk Score	Probability x Impact	12
Owner	Person responsible for monitoring	Sarah Chen, Engineering Lead
Mitigation Strategy	Actions to reduce probability or impact	Cross-train second developer, document architecture
Contingency Plan	What to do if risk materializes	Engage contract developer from approved vendor list
Status	Open, Mitigating, Closed, Occurred	Mitigating
Last Reviewed	Date of most recent review	2025-02-15

Scoring Risks

Use a 5x5 probability-impact matrix. The scores are not scientific — they represent the team’s collective judgment and exist to prioritize which risks deserve attention.

Probability Scale:

• 1 — Rare: Less than 10% chance
• 2 — Unlikely: 10-25%
• 3 — Possible: 25-50%
• 4 — Likely: 50-75%
• 5 — Almost Certain: Greater than 75%

Impact Scale:

• 1 — Negligible: Minor inconvenience, no schedule effect
• 2 — Minor: Small delay or cost increase, manageable
• 3 — Moderate: Noticeable schedule slip or budget impact
• 4 — Major: Significant delay, scope reduction needed
• 5 — Critical: Project failure, cancellation risk

Risks scoring 15-25 are critical and need active mitigation. Scores of 8-14 should be monitored closely. Below 8, log them and review monthly.

Identifying Risks

Risk identification is not a one-time activity. Run a dedicated risk identification session at project kickoff, then review and add risks throughout the project lifecycle.

Brainstorming. Gather the team and walk through each phase of the work breakdown structure. At each work package, ask: “What could go wrong here? What assumptions are we making?”

Historical review. Check post-mortem documents from similar past projects. The risks that bit previous teams are likely to appear again.

Checklist review. Use a risk category checklist to ensure coverage across domains:

• Technical: Architecture decisions, technology maturity, integration complexity
• Resource: Key person dependencies, skill gaps, vendor availability
• Schedule: Dependency delays, estimation accuracy, external milestones
• Scope: Requirements ambiguity, scope changes, stakeholder alignment
• External: Market changes, regulatory shifts, vendor bankruptcy
• Organizational: Budget cuts, reorganization, competing priorities

Pre-mortem. Run a hypothetical exercise: “It is six months from now and this project has failed. What went wrong?” This technique, developed by psychologist Gary Klein, bypasses optimism bias and surfaces risks the team subconsciously avoids discussing.

Mitigation Strategies

For each high-priority risk, choose one of four strategies:

Avoid. Eliminate the risk by changing the project plan. If a risky technology integration threatens the timeline, substitute a proven alternative. Avoidance changes scope but removes the risk entirely.

Mitigate. Reduce the probability or impact. Cross-training team members mitigates key-person dependency. Building a prototype mitigates technical uncertainty. Mitigation costs time and money upfront but reduces exposure.

Transfer. Shift the risk to a third party. Fixed-price vendor contracts transfer delivery risk to the vendor. Insurance transfers financial risk. Transfer does not eliminate risk — it moves ownership.

Accept. Acknowledge the risk and prepare a contingency plan without active mitigation. Some risks are too unlikely or too expensive to mitigate. Acceptance is a valid strategy when the cost of mitigation exceeds the expected loss.

Document the chosen strategy in the register along with specific actions, owners, and deadlines.

Reviewing the Risk Register

A risk register that is created at kickoff and never reviewed is theater. Schedule risk reviews:

• Weekly during standups or team meetings: Quick scan of top-5 risks. Any changes in status?
• Biweekly with the PM and risk owners: Detailed review of all open risks. Update scores based on new information.
• Monthly at stakeholder reviews: Present top risks with mitigation progress. Stakeholders may surface risks the project team cannot see.

During reviews, ask:

• Have any risks materialized? Move them to “Occurred” and activate the contingency plan.
• Have probability or impact changed? Re-score accordingly.
• Are there new risks? Add them immediately.
• Have mitigation actions been completed? If a mitigation has reduced a risk’s score below the threshold, the team can reduce monitoring effort.

Tool Options

Spreadsheets work for small projects. Google Sheets or Excel with conditional formatting on risk scores gives a clear visual. Color-code cells: red for 15+, yellow for 8-14, green for below 8.

Jira can track risks as a custom issue type with fields for probability, impact, and owner. This integrates risk tracking into the team’s existing workflow.

Smartsheet and Monday.com offer risk register templates with dashboards and automated reminders for review dates.

Dedicated tools like RiskWatch or ARM (Active Risk Manager) are overkill for most teams but make sense for large programs with hundreds of tracked risks.

Connecting Risks to the Schedule

High-impact risks should be reflected in your project timeline. If there is a 40% chance that a vendor delivery slips by two weeks, add a two-week buffer after that dependency in the schedule. This is not padding — it is risk-adjusted planning. Communicate it as such to stakeholders who question timeline buffers.

Link risks to specific milestones so that when you review milestone readiness, the associated risks are visible. A milestone with three unmitigated high-scoring risks attached deserves more scrutiny than one with all risks in the green zone.

A risk register is only as good as the team’s discipline in maintaining it. Treat it as a living tool, not a compliance artifact, and it will earn its place in every project meeting.