Risk Register

In PRINCE2, the Risk Register is the central record of all identified threats and opportunities that could affect the objectives of a change. Risks are captured as soon as they are identified, assessed against probability and impact, assigned to an owner, and managed until they are mitigated or accepted. The register provides visibility of the overall risk exposure. Change Request End Stage and End Change Reports summarise the Risks specific to that Change Request.

Key Principle: All changes involve risk. The purpose of the Risk Register is not to eliminate risk but to ensure that every identified risk is owned, understood, and actively managed. A change with no recorded risks is not a low-risk change — it is a change that has not been properly assessed.

Important: A stage cannot progress while there are open, unmitigated risks. All active risks must be mitigated or formally accepted before a stage boundary is authorised. This enforces the PRINCE2 principle that the Change/Board must be satisfied the risk exposure is acceptable before committing to the next stage.

The Register

The Risk Register displays all risks across the system, divided into two sections: Active Risks and Mitigated Risks. Risks are grouped by Change Request within each section. Click any row to open the risk detail and view or update it.

Columns

Grouping by Change Request

Active and mitigated risks are grouped under their parent Change Request, identified by CR Number and title. This makes it straightforward to assess the total risk exposure for a specific change and to identify which change requests carry the most open risk at any given time.

Active Risks

The upper table lists all risks that have not yet been mitigated. These are the risks currently affecting change requests in progress. Each one requires an owner, an assessed response strategy, and a plan for mitigation.

Note: The age of an active risk (Days Open) is a meaningful signal. A risk that has been open for an extended period without a response plan may indicate that it needs escalating, that the stage is understaffed, or that the risk has been implicitly accepted without being formally recorded as such. All three situations require attention.

Mitigated Risks

The lower table provides a complete historical record of risks that have been formally mitigated. Mitigated risks are retained for audit purposes and to support lessons-learned analysis. The Days to Mitigation column allows patterns to be identified — for example, consistently slow mitigation of a particular risk category may indicate a process improvement opportunity worth capturing as a lesson.

Risk Detail

Clicking any row in the register opens the Risk Detail dialog. The dialog operates in three modes:

• Create — Opened from within a Change Request or Task to log a new risk.
• Edit — Opened from the register for an active risk, allowing all fields to be updated and the risk to be mitigated.
• View — Opened for a mitigated risk. The record is read-only once mitigation has been confirmed.

Risk Matrix

The risk matrix is displayed at the top of the detail dialog whenever probability and impact have been set. It provides an immediate visual representation of where this risk sits relative to the tolerance threshold.

The matrix plots the risk by probability (vertical axis) and impact (horizontal axis). The position of the risk indicator shows its assessed severity at a glance:

If the risk Exceeds Tolerance — indicated by a red banner on the matrix — it must be escalated to the project board. A risk exceeds tolerance when both probability and impact are High or Very High, or when impact is Very High and probability is Medium or above. Risks at this level cannot be managed by the change manager alone.

Risk Fields

Risk Number

A unique system-generated reference assigned when the risk is first saved (e.g. R-001). This number is used to reference the risk in the Business Case, stage reviews, and escalation reports.

Risk Title *

A short, descriptive label for the risk. The title should identify the risk at a glance and distinguish it from other risks on the same change request.

Examples: Key supplier unavailable during implementation or Regulatory approval delayed beyond stage end date

Risk Category

Classifies the nature of the risk to support analysis and reporting across the register:

Risk Type *

Whether this risk is a Threat or an Opportunity.

• Threat — An uncertain event that would have a negative impact on objectives if it occurred.
• Opportunity — An uncertain event that would have a positive impact on objectives if it occurred.

Both types require formal management. Opportunities should be actively exploited where possible, not simply noted and ignored.

Risk Cause *

Describes the source or trigger of the risk — the conditions or circumstances that could give rise to it. This is the first element of the PRINCE2 cause–event–effect structure for expressing risk.

A well-written cause is specific and observable. Vague causes such as “project complexity” are difficult to own and hard to respond to. A specific cause such as “the third-party API has no published SLA” gives the risk owner something concrete to act on.

Risk Event

Describes what could actually happen — the uncertain event itself. This is the second element of the cause–event–effect structure.

Example: The API becomes unavailable during the integration testing phase.

Risk Effect

Describes the consequence for the change’s objectives if the risk event occurs. This is the third element of the cause–event–effect structure and grounds the risk in terms of the tolerances that matter — time, cost, quality, scope, or benefits.

Example: Integration testing cannot be completed within the planned stage, delaying the change end date by up to three weeks.

Tip: Completing all three fields — Cause, Event, and Effect — produces a risk entry that is unambiguous, actionable, and directly traceable to change objectives. A risk with only a title and a probability score cannot be effectively owned or escalated.

Probability *

The assessed likelihood that the risk event will occur:

Impact *

The assessed severity of the effect on change objectives if the risk event occurs:

Exceeds Risk Tolerance?

Calculated automatically from the probability and impact ratings. If the combination places the risk above the tolerance threshold, this field displays YES — Requires Escalation in red.

Risks that exceed tolerance cannot be managed at the change manager level. They must be formally escalated to the project board, who will decide whether to adjust tolerances, request an exception plan, or instruct premature closure of the change.

Proximity

How soon the risk could materialise:

Proximity informs the urgency of the response. A high-impact risk with immediate proximity demands a different response than the same risk assessed as long-term.

Velocity

How quickly the risk would affect objectives once it occurs. Velocity is distinct from proximity — a risk may be unlikely to occur soon but would have an almost instantaneous effect if it did.

High-velocity risks require contingency plans to be in place before the risk occurs, not after. If a high-velocity risk materialises without a contingency plan, the stage will breach tolerance before corrective action can be taken.

Response Option

The selected strategy for managing this risk. PRINCE2 defines different responses for threats and opportunities:

For Threats:

For Opportunities:

Response

A free-text description of the specific actions being taken in line with the selected response option. This should be concrete and assigned — a response that says “monitor closely” without specifying who will monitor, what they are looking for, and what they will do if the risk materialises is not a response plan. A good response entry identifies what will be done, by whom, and by when.

Risk Owner

The person assigned accountability for managing this risk. The risk owner is responsible for monitoring the risk, implementing the agreed response, and escalating if circumstances change.

The risk owner should be the person most capable of managing the specific risk — not necessarily the change manager. A regulatory risk is best owned by someone with direct access to compliance information; a technical risk by someone with the relevant technical authority.

Important: Every active risk must have a named owner. Unowned risks cannot be effectively monitored or escalated and represent a gap in the risk management approach that will be visible at stage reviews.

Date Identified / Date Last Reviewed

Both dates are managed automatically by the system. Date Identified is set when the risk is first created. Date Last Reviewed is updated each time the risk record is saved, providing an audit trail of when the risk was last actively considered. A risk that has not been reviewed recently should be reassessed — circumstances change, and a risk that was low-probability last month may not be low-probability today.

Actions

Create Risk

Available when opening the Risk Detail in create mode from a Change Request or Task. All required fields — Title, Cause, Probability, Impact, and Risk Type — must be completed before the risk can be saved. The Risk Number is assigned automatically on creation.

Save

Updates the risk record without changing its mitigation status. Use this to record changes to the response plan, revise probability or impact assessments as new information becomes available, or assign or change the risk owner. The risk remains Active.

Mitigated

Formally closes the risk, recording the date of mitigation and moving it from the Active table to the Mitigated Risks table. The current form state — including the response description — is saved as part of the mitigation record, so the response field should accurately reflect what was actually done before this button is clicked.

A risk should only be marked as mitigated when:

• The response has been fully implemented
• The threat no longer exists or has been reduced to an acceptable residual level, or the opportunity has been realised or is no longer available
• Any follow-on actions — such as a lessons log entry or a related issue closure — have been initiated

Once mitigated, the risk record becomes read-only.

Note: Marking a risk as mitigated when the response is only partially implemented is a common error. If the threat still exists but at a reduced level, the correct action is to update the probability and impact ratings to reflect the residual risk position, not to close the record. The residual risk that remains after a response must itself be assessed — if it still exceeds tolerance, escalation is still required.

Cancel

Discards any unsaved changes and closes the dialog. The risk record is returned to its last saved state.

Relationship to Other Records

Business Case — The Business Case (Section 8) summarises the key risks affecting the viability of the change. Risks added during Business Case preparation are automatically created in the Risk Register when the Business Case is saved. The two records should remain consistent — a risk that is prominent in the Business Case narrative should be visible and actively managed in the register.

Stage Progression — A stage cannot advance while there are open, active risks against the associated change request. This is a hard constraint. If a risk cannot be mitigated before the stage boundary, it must either be formally accepted with a documented rationale, or an exception report must be raised for the project board to consider adjusting the stage tolerances or replanning the approach.

Issue Register — If an assessed risk actually occurs, it transitions from the Risk Register to the Issue Register. An event that was uncertain (a risk) becomes a fact that requires management (an issue). The two registers should be reviewed together at stage boundaries to confirm that no risks have materialised without being captured as issues, and that no issues have been raised that should have been anticipated as risks earlier in the process.