Project template
Project Risk Register Template for Small Teams
A lightweight risk log that helps a project owner record uncertainty, warning signs, actions and follow-up.
What belongs in a small-team risk register
A risk register records uncertain events that could affect a project, the signs that make them more likely, and the actions the team can take. It does not need to predict everything. Keep the list short enough to review and focus on risks that could change scope, timing, cost, quality or acceptance.
Copyable project risk register
One row for each risk
Project: Risk ID: Risk statement (if [uncertain event], then [possible effect]): Cause: Probability (use team-defined scale): Impact (schedule / cost / quality / customer / other): Trigger or warning sign: Mitigation before the risk happens: Contingency if it happens: Owner: Next review date: Status (open / monitoring / action in progress / occurred / closed):
| Field | How to use it |
|---|---|
| Risk statement | Describe an uncertain event and the consequence it may have. |
| Cause and trigger | Record why it might happen and what observable sign would prompt action. |
| Probability and impact | Use a scale your team defines. Consider schedule, cost, quality and customer effects. |
| Mitigation and contingency | State what can be done before the event and what the team will do if it happens. |
| Owner and review date | Name one person to monitor it and the next date it will be reviewed. |
| Status | Use a small set of states the team understands, and close risks that no longer apply. |
How to score probability and impact
Low, Medium and High can be enough for a small team, but define what each label means in your context. For example, your team might describe High impact as likely to move an agreed launch date or prevent acceptance. These labels are a suggested working scale, not an industry standard or a precise forecast. Do not multiply scores and treat the result as certainty.
Worked example (fictional)
- Risk: Client feedback may arrive after the agreed review date and delay approval.
- Cause: The client approver has not confirmed a review window.
- Probability / impact: Medium / High, as an illustrative team judgment.
- Trigger: No response by Wednesday afternoon.
- Mitigation: Confirm the approver and review slot at the start of the week.
- Contingency: Move dependent work and tell the delivery owner the revised date.
- Owner / review: Account lead / Wednesday.
A short weekly risk review
- Ask whether probability, impact or the trigger has changed.
- Check if the mitigation is moving and whether a decision is needed.
- Assign an owner and next review date to any new material risk.
- Close risks that no longer apply.
- If a risk has happened, move it to the issue or task workflow so it gets an action and due date.
When to escalate a risk
Escalate when the possible impact is outside the project owner’s authority, when a trigger has appeared, or when the current response cannot protect an agreed outcome. State the decision required, who can make it and by when.
Frequently asked questions
How many risks should a small project have?
There is no universal number. Start with risks that could materially affect scope, timing, cost, quality, safety or customer acceptance.
What is the difference between a risk register and an issue log?
A risk register tracks uncertain events that may happen. An issue log tracks problems that have already occurred and need resolution.
Who owns the risk register?
The project owner can maintain the register. Each risk should still have one named person responsible for monitoring it.
How often should a risk register be reviewed?
Weekly is a useful starting point for many projects. Review more often when delivery changes quickly or a trigger is near.
Turn mitigation into owned work
When a risk needs action, give that action an owner and a due date. Review the operations workflow page and project management workspace for Clarityy’s published project and task tracking. The guide to tracking multiple projects covers a related coordination problem.