How_to_Use_This_Risk_Register_Template
📖 How to use this template
A risk register is a living list of what could go wrong on your project and what you are doing about each one. It only works if it gets reviewed and the entries actually change. This one has a 5×5 scoring matrix, a review cadence and twenty sample risks, so you can see it working before you replace them.
- Duplicate this project into your own organization (dropdown next to the project name, then
Duplicate) - Switch to Table view. This register is built around custom fields, and Table view is where they are visible side by side. List view works, but you lose the comparison.
- Sort by Risk Score, descending. That single action turns the register into a priority list. It is the most useful thing you will do here.
- Read the sample risks. Each one shows the four parts of a well-written entry: the risk statement, the trigger, the consequence, and the current response.
- Delete the samples, keep the scaffolding. Remove the sample risks once you understand the shape. Keep the sections, the custom fields, the statuses and the governance tasks at the bottom.
- Add your own risks. Start with five. A short register that gets reviewed beats a long one that does not.
The custom fields
| Field | Type | What it is for |
|---|---|---|
| Risk ID | Text | A stable reference (R-01, R-02…) so you can cite a risk in meeting notes without pasting the whole title. |
| Category | Select | Which part of the project is exposed. Lets you spot clustering — five risks in one category usually means a structural problem, not five separate problems. |
| Likelihood | Select | How probable, scored 1 (Rare) to 5 (Almost Certain). |
| Impact | Select | How bad if it happens, scored 1 (Negligible) to 5 (Severe). |
| Risk Score | Number | Likelihood × Impact, so 1 to 25. Your sort order. |
| Risk Level | Select | The score bucketed into Low / Medium / High / Critical. Your colour code. |
| Response Strategy | Select | Avoid, Mitigate, Transfer, Accept or Escalate. Every risk needs exactly one. |
| Date Identified | Date | When it went on the register. Useful for spotting entries nobody has looked at in months. |
Why Risk Score is a number you type rather than a formula. Quire formula fields cannot multiply two Select fields, so this one is manual. It takes two seconds and it keeps the Likelihood and Impact labels readable, which matters more than the automation.
The 5×5 scoring matrix
Multiply Likelihood by Impact. The result lands in one of four bands.
| ↓ Likelihood / Impact → | 1 Negligible | 2 Minor | 3 Moderate | 4 Major | 5 Severe |
|---|---|---|---|---|---|
| 5 Almost Certain | 5 | 10 | 15 | 20 | 25 |
| 4 Likely | 4 | 8 | 12 | 16 | 20 |
| 3 Possible | 3 | 6 | 9 | 12 | 15 |
| 2 Unlikely | 2 | 4 | 6 | 8 | 10 |
| 1 Rare | 1 | 2 | 3 | 4 | 5 |
What each band obliges you to do
| Band | Score | Required response |
|---|---|---|
| Low | 1–4 | Accept and note. Review quarterly. No action plan needed. |
| Medium | 5–9 | Named owner, documented response. Review monthly. |
| High | 10–14 | Named owner, funded mitigation plan with dates. Review weekly. |
| Critical | 15–25 | Escalate to sponsor. Contingency reserved. Review weekly and report to the steering group. |
Two scoring mistakes worth avoiding
Everything scores a 4. If most of your register lands in High, your scale is not discriminating and the register has stopped being a priority list. Force a spread. Something has to be a 1.
Scoring the wrong impact. Score the impact on the project objective, not the general unpleasantness of the event. A supplier going bankrupt sounds dramatic, but if you have two other suppliers the project impact is Minor.
The five response strategies
Avoid — Change the plan so the risk cannot occur. Drop the feature that depends on the unproven API. Cheapest option when available, but it usually costs you scope.
Mitigate — Reduce the likelihood, the impact, or both. Run a two-week spike before committing to the architecture. The default choice for most High risks.
Transfer — Move the financial consequence to someone else. Insurance, fixed-price contracts, warranty clauses, penalty terms. Note that transfer moves the cost, not the disruption. You still lose the time.
Accept — Acknowledge it, budget for it, do nothing else. Perfectly valid for Low risks, and it requires a documented decision plus ideally a contingency figure. Accept is a choice, not an absence of one.
Escalate — This sits outside your authority to resolve. Push it to the sponsor with a recommendation attached. Escalating is not passing the buck if you bring an option with it.
The test for a good response
If your mitigation cannot be written as a task with an owner and a due date, it is not a mitigation. It is a wish. "Monitor the situation" and "communicate closely with the vendor" both fail this test.
The workflow statuses
A risk moves through these as your response develops. The risk itself never "completes" — your handling of it does.
| Status | Meaning |
|---|---|
| Identified | On the register, not yet assessed. |
| Analyzing | Working out likelihood, impact and what is actually at stake. |
| Planning Response | Scored, deciding what to do about it. |
| Mitigating | Response plan is active and the actions are running. |
| Monitoring | Response is in place. Watching for the trigger. |
| Closed | Can no longer occur, or the exposure is permanently gone. |
How the structure works
Sections group risks by category so you can see clustering at a glance.
Each risk is a task. The assignee is the risk owner — one named person, never a team. If nobody owns it, it will not get managed. That is the single most reliable predictor of a register going stale.
Subtasks are the mitigation actions. Each risk holds its concrete steps underneath, with their own owners and dates. This is what separates a register that changes things from a register that describes things.
Tags cut across the categories:
Trigger Fired— the early warning has already activated. Look at these first.Launch Blocker— will stop the release if unresolved.Escalated to Sponsor— outside the team's authority.Contingency Reserved— budget is set aside for this one.Needs Re-scoring— the situation has changed since it was last assessed.
The review cadence
The governance section at the bottom of the register holds these as recurring tasks, so they show up whether or not anyone remembers them.
| Rhythm | What happens |
|---|---|
| Weekly | Review High and Critical only, sorted by score. About 30 minutes. |
| Fortnightly | Twenty minutes at the end of sprint planning to add what is missing. |
| Monthly | Re-score the whole register, close what no longer applies. |
| Quarterly | One-page report to the steering group. |
Three questions per risk at the weekly review
- Has the score changed since last week, and does the Risk Level need updating?
- Is the mitigation actually moving, or has it been "in progress" for three weeks?
- Has the trigger fired?
A review that ends with no field changed anywhere on the register is a review that did not happen.
Writing a good risk entry
The sample risks all follow the same four-part shape. Copy it.
Risk statement. What could happen, with a number attached wherever possible. "Cloud spend could rise from $42k to $58k monthly" is workable. "Costs might increase" is not.
Trigger or early warning. The observable signal that this is becoming real. Without one you are relying on somebody noticing, which is not a control.
Consequence if realised. What it actually does to the project. This is what justifies the Impact score.
Current response. The strategy plus the specific actions, which live as subtasks.
One habit that pays off later
When you close a risk, write down whether it occurred, what the actual impact was compared to the predicted one, and whether you would score it the same way again.
That last question is the only part of risk management that makes the next project easier. Skipping it is why most organisations score risks no better in year five than they did in year one.