Skip to content

Risk Register

At a glance

  • Purpose: Record uncertain events that would matter if they occurred, how serious they are, what will be done, and who owns the response.
  • Use it when: From initiation and reviewed at every reporting cycle. It is the living counterpart to the issue log, which holds what has already happened.
  • Owner: The project manager maintains it; each risk has its own named owner.
  • Related: Module 08 · Lab 11 · Lab 17

A risk register records uncertain events that would matter if they occurred, what you will do about them, and who owns the response.

Copy the skeleton below and replace the bracketed text.

Register skeleton

# Risk Register — [Project name]

| | |
| --- | --- |
| **Date** | [YYYY-MM-DD] |
| **Owner** | [Who maintains this register] |

## Scoring

Score **probability** and **impact** as 1 (low), 2 (medium), or 3 (high). Exposure = product.
Anything scoring 6 or above needs an explicit response and a named owner.

## Risks

| ID | Risk | Type | Probability | Impact | Exposure | Response | Owner | Trigger |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| R1 | [What might happen] | Threat | 2 | 3 | 6 | [Response] | [Who] | [Early warning sign] |
| R2 | [What might happen] | Opportunity | 2 | 2 | 4 | [Response] | [Who] | [Sign] |

## Response detail

For every risk at exposure 6 or above, describe the response.

**R1 — [Risk]**
- **Strategy:** [Avoid | Mitigate | Transfer | Accept]
- **Actions:** [What will be done, by when]
- **Contingency:** [What happens if it occurs despite the response]
- **Residual exposure:** [Exposure after the response]

## Closed and converted risks

| ID | Risk | Outcome | Date |
| --- | --- | --- | --- |
| R3 | [Risk] | [Resolved — how] | [Date] |
| R4 | [Risk] | [Occurred — now tracked as an issue] | [Date] |

How to use this template

  1. Write each risk as cause → uncertain event → effect. "If the records office does not confirm the retention period, the retention configuration will be wrong, creating a compliance exposure" is a risk. "Poor requirements" is a category.
  2. Score with a consistent rule: use the risk assessment matrix so that a 6 means the same thing in every row.
  3. Give the risks above the threshold a named owner and a written response, detailed using the risk response plan.
  4. Record a trigger for every planned response. A risk with no observable early warning will be discovered as an issue instead.
  5. Include opportunities. A register containing only threats distorts judgement and misses cheap wins.
  6. Review at every reporting cycle and re-score. Close risks with an outcome — resolved, occurred, or no longer applicable — rather than letting rows persist.

Field descriptions

Field What goes in it Watch out for
ID Stable reference (R-01) Reusing IDs after closure
Risk Cause → event → effect A category rather than a specific event
Type Threat or opportunity Threats only
Probability / Impact 1–3 each, per the agreed scale Scores with no scale behind them
Exposure Probability × impact Averaging instead of multiplying
Response The strategy and the action "Monitor closely"
Owner A named person who can act The PM for every risk
Trigger The observable early warning A trigger nobody is watching for
Residual exposure Exposure after the response Assuming the response fully works
Status Open / occurred / closed / no longer applicable Rows that never change state

Response strategies

For threats For opportunities
Avoid — remove the cause Exploit — make it more likely
Mitigate — reduce probability or impact Enhance — increase the benefit
Transfer — move the consequence to someone else (for example insurance, a contract) Share — partner with someone who can help
Accept — do nothing, but track it deliberately Accept — do nothing, but track it deliberately

Worked example

From Lab 11, on the admission portal — invented for teaching. Three rows written properly, and one written badly:

ID Risk Type P I Exposure Response Owner Trigger
R-01 The eligibility rule set is not agreed before build starts, so the rules engine must be rebuilt, causing 10 days of rework on the critical path Threat 3 3 9 Sequence the engine after sign-off — see response plan Business owner Sign-off not obtained by the design milestone
R-02 The security review queue is longer than assumed, so the integration review slips, delaying testing Threat 3 3 9 Transfer to an assessor with a service commitment PM Request not acknowledged within 3 days
R-03 The vendor's unused licence tier is offered at no cost, so licence spend falls Opportunity 1 2 2 Ask, in writing, at contract review PM Contract review date
— "Requirements may be unclear" Threat 2 2 4 "Monitor closely" The team —

The fourth row is the one to learn from: it has a score, so it looks like analysis, but the event is a category rather than a specific occurrence, the owner is a group, the response is the absence of one, and there is no trigger. Rows like this inflate a register's length while providing no control — and they are usually a sign that identification stopped at the first plausible-sounding phrase.

Common mistakes

  • A risk is not an issue. An issue has already happened and needs a different process — see the issue log. Occurred risks should be closed here and tracked there.
  • Every risk at high exposure needs an owner — a person, not a team.
  • A trigger makes a risk actionable. "We will know it is happening when…" turns a vague worry into something monitorable.
  • Include opportunities. A register of nothing but threats trains you to be pessimistic, not realistic.
  • Review the register regularly; risks that are never revisited are just a document.
  • Categories instead of risks. "Scope creep", "resource availability", and "integration risk" cannot be assessed, owned, or triggered.
  • Scores with no scale. If two people score the same risk differently with no shared definition, the exposure column is decoration.
  • Residual exposure never updated. A register that looks identical at initiation and at close has not been used to make decisions.
  • Registering the response as the risk. "We may need to add a developer" is a response to an unnamed event; the event is what should be scored.