Risk Register
The Risk Register is a formal risk management tool that scores each risk using a probability × impact matrix, producing a numerical score from 1 to 25. Every risk has a documented mitigation plan, a named owner, and a clear status. Designed for structured reporting and senior stakeholder communications, the Risk Register complements the RAID Log by providing the rigour and scoring framework required for steering committee packs, board reports, and formal project governance gates.
Overview
The Risk Register provides a structured, quantified approach to managing project risks. Where the RAID Log is a broad governance register covering all four categories (Risks, Assumptions, Issues, Decisions), the Risk Register focuses specifically on risks and applies a formal scoring methodology: each risk is rated for both Probability (1–5, from Very Low to Very High) and Impact (1–5, from Very Low to Very High). These two scores are multiplied together to produce a Risk Score between 1 and 25. The score determines the risk band and drives prioritisation, escalation, and reporting. Every risk also has a documented mitigation plan that must be specific and actionable — not simply "monitor the situation."
Risk scores are grouped into three colour-coded bands that align with standard project governance frameworks. High risks (15–25) are shown in red and require immediate attention, active mitigation, and regular reporting to senior stakeholders. These are risks that, if they materialise, could threaten the project's timeline, budget, or outcome. Medium risks (8–12) are shown in amber and need active monitoring and a clear mitigation plan, but do not yet require escalation. Low risks (1–6) are shown in green and should be documented and tracked, but are unlikely to affect the project materially without a change in circumstances. Scores of 7 and 13–14 fall between the standard bands and are treated as the upper bound of the lower band in each case.
The Risk Register is more structured and formal than the RAID Log and is specifically designed for use in senior stakeholder communications. When presenting to a steering committee or board, the Risk Register provides the numerical evidence of risk exposure and demonstrates that mitigation plans are in place. It is typically reviewed monthly at minimum — and weekly during active migration phases — with score changes tracked over time to show whether the overall risk profile is improving or deteriorating. The combination of current score, residual risk (score after mitigation), and status gives executives a complete picture of where the project stands.
When to use this
- Project planning: Build the initial Risk Register during the planning phase by scoring all identified risks before the first migration wave begins.
- Monthly risk reviews with the steering committee: Use the Risk Register as the formal agenda item for risk reporting, showing scores, changes since last review, and mitigation progress.
- When a new significant risk emerges: Any risk that warrants a score of 8 or higher should be added to the Risk Register immediately, not held until the next review cycle.
- Go/no-go gates: Review all High and Medium risks before approving each migration wave. No wave should proceed with unmitigated High risks unless formally accepted by the project sponsor.
- Final closure reporting: At project close, document how each risk was managed, whether it materialised, and what the final residual risk was. This informs future project planning.
Key features
Step-by-step instructions
Creating a risk
RSK-0014) when the record is saved.Using the risk scoring matrix
Use this matrix to determine the Risk Score from a combination of Probability and Impact. The colour coding indicates the risk band: green (Low, score 1–6), amber (Medium, score 8–12), and red (High, score 15–25).
| Probability \ Impact | 1 — Very Low | 2 — Low | 3 — Medium | 4 — High | 5 — Very High |
|---|---|---|---|---|---|
| 1 — Very Low | 1 | 2 | 3 | 4 | 5 |
| 2 — Low | 2 | 4 | 6 | 8 | 10 |
| 3 — Medium | 3 | 6 | 9 | 12 | 15 |
| 4 — High | 4 | 8 | 12 | 16 | 20 |
| 5 — Very High | 5 | 10 | 15 | 20 | 25 |
Adding and updating mitigation plans
Closing a risk
Exporting for board reports
Important fields
| Field | Required / Optional | Description |
|---|---|---|
| Risk ID | Auto-generated | A unique identifier assigned automatically when the risk is saved (e.g., RSK-0001). Used to reference risks in steering committee papers and communications. |
| Category | Required | The risk category: Technical (infrastructure, tooling, integrations), Operational (people, process, dependencies), Security (compliance, vulnerabilities), or Commercial (budget, contracts, third-party). |
| Description | Required | A clear statement of the risk using the format: "There is a risk that [event] will occur, resulting in [consequence]." The more specific and concrete the description, the easier the risk is to manage and track. |
| Probability | Required | How likely the risk is to occur, scored 1–5: 1 = Very Low, 2 = Low, 3 = Medium, 4 = High, 5 = Very High. Score based on evidence, not instinct. |
| Impact | Required | The severity of the consequence if the risk materialises, scored 1–5: 1 = Very Low, 2 = Low, 3 = Medium, 4 = High, 5 = Very High. Consider impact on timeline, budget, and project outcomes. |
| Risk Score | Auto-calculated | Probability × Impact. Range: 1–25. Automatically calculated whenever Probability or Impact is changed. Banded as: Low (1–6, green), Medium (8–12, amber), High (15–25, red). |
| Mitigation Plan | Required | The specific actions being taken to reduce the probability or impact of the risk. Must be concrete and actionable — "monitor the situation" is not an acceptable mitigation plan. Include responsible parties and deadlines where possible. |
| Owner | Required | The named individual accountable for managing this risk and driving the mitigation plan to completion. Must be a specific person, not a team or role. |
| Status | Required | The current state of the risk: Open (active, requires monitoring and mitigation), Mitigated (mitigation applied, residual risk is acceptable), Accepted (team has formally accepted the risk), or Closed (no longer relevant). |
| Residual Risk | Optional | A free-text description or score indicating the expected level of risk that remains after the mitigation plan is fully implemented. Helps stakeholders understand the end state, not just the current exposure. |
Example workflow
During the planning phase of a major data centre migration, the project team conducts a risk workshop and identifies 12 risks across Technical, Operational, and Security categories. The risks are entered into the Risk Register and scored individually. Eleven risks score between 4 and 12. One risk stands out immediately with a score of 20.
The high-scoring risk is described as: "There is a risk that the target network environment will not be fully provisioned and tested before the go-live date, resulting in a delay to the migration of all 47 production servers in Wave 3." It has been scored Probability = 4 (High) and Impact = 5 (Very High), giving a Risk Score of 20 — firmly in the red band. The risk is assigned to the infrastructure lead with the following mitigation plan: "Obtain written confirmation from the Network team each Monday that provisioning is on track for the agreed completion date. If confirmation is not received by T-14 (14 days before go-live), escalate immediately to the CTO and invoke the contingency plan to defer Wave 3 by one week."
The risk is reviewed weekly at the steering committee. For three weeks it remains Open with a score of 20 while the network team works through provisioning. At the T-14 checkpoint, the infrastructure lead confirms that network provisioning is complete and has been successfully tested end-to-end. The mitigation plan has worked as intended. The project manager opens the risk, updates the Description to document the confirmation received, and revises the scores: Probability drops from 4 to 2 (the network is now provisioned — the remaining risk is only of a last-minute failure), and Impact drops from 5 to 2 (even if a problem emerged now, there is time to address it before go-live). The new Risk Score is 4 — firmly in the green band. Status is set to Mitigated and the Residual Risk field is updated: "Network confirmed ready at T-14. Residual risk is minor configuration issues discoverable during final checks."
The steering committee presentation that week shows a risk profile that has improved materially: one High risk has moved to Low, and the overall register shows 0 red risks for the first time in the project. The documented journey from score 20 to score 4 — with the mitigation plan that drove the change clearly recorded — gives the board the evidence they need to approve Wave 3 proceeding on schedule.
Tips & best practices
Over-scoring risks (everything is a 4 or 5) creates alarm fatigue: stakeholders stop taking red risks seriously because everything is red. Under-scoring hides real problems until it is too late to act. Calibrate your scores by reviewing the whole register at once — if you have 12 risks all scoring 15 or above, ask yourself honestly whether they are all truly High. Compare risks against each other, not just in isolation.
A mitigation plan like "monitor the situation and escalate if needed" is not a plan — it is an observation. A good mitigation plan names a specific action, a specific person, and a specific trigger or deadline. For example: "Infrastructure lead to obtain written sign-off from Network team by T-14. If not received, escalate to CTO and invoke one-week deferral contingency." If you cannot write a concrete plan, the risk is either not well understood yet, or needs to be escalated before you can mitigate it.
Risk scores are not static — they change as mitigations take effect, as dependencies are resolved, and as the project progresses. During the active migration phase (typically the four to eight weeks before each wave), review every open risk score weekly, not monthly. A risk that was Medium at the start of the month may have become High because a mitigation action was not completed on time.
When closing or mitigating a risk, document what the residual risk looks like — what exposure remains after the mitigation has been applied. This is valuable both for the current project (it shows stakeholders the true final state, not just "risk closed") and for future projects (lessons learned documentation is far more useful with residual risk data than without it).
Common mistakes
It can be tempting to score all risks as Low or Medium to avoid uncomfortable conversations with the steering committee or board. This is one of the most dangerous things a project manager can do. High risks that are under-scored do not get the attention and resources needed to mitigate them — and when they materialise, the project team has no documented evidence that the risk was known and managed. Score honestly; it protects both the project and the project manager.
Mitigation plans that say "be careful," "monitor closely," or "engage with the relevant team" provide no real governance value. They do not tell the owner what to do, by when, or how to know when the risk has been adequately mitigated. If your mitigation plan cannot be acted on by someone who knows nothing about the risk's history, rewrite it until it can. Vague plans also make it impossible to hold owners accountable.
A common failure is to add a mitigation plan to a risk and then leave the score unchanged for weeks, even after the mitigation has been implemented. If your mitigation works, the Probability or Impact should reduce — and the score should reflect that. Stakeholders who see a risk score of 20 week after week will escalate it, even if the underlying situation has improved significantly. Update scores when circumstances change.
The Risk Register is specifically for things that have not yet happened. Once a risk materialises — once the problem is actually occurring — it should be logged as an Issue in the RAID Log. Keeping materialised risks in the Risk Register as "Open" gives a distorted picture of the risk profile: it appears the team is managing a potential problem when in fact they are dealing with an active one. Close the risk (mark it as an Issue having occurred) and open the corresponding Issue in the RAID Log immediately.