8.2 The 5-Step Risk Management Procedure (Identify, Assess, Plan, Implement, Communicate)

The 5-Step Risk Management Procedure in PRINCE2 7

Practitioner Core Mandate: Risk management in PRINCE2 7 is not an ad-hoc, instinctual reaction to crises; it is a systematic, repeatable management cycle. The recommended 5-Step Risk Procedure—comprising Identify, Assess, Plan, Implement, and Communicate—ensures that uncertainty is handled with analytical rigor and transparent governance. Crucially, the procedure integrates continuous bidirectional communication across every phase, guaranteeing that decision-makers at all levels maintain real-time visibility over threats and opportunities.

---

1. Overview of the 5-Step Risk Procedure

The PRINCE2 7 risk procedure provides a structured framework that can be tailored to any project environment, scale, or industry sector:

                    THE PRINCE2 7 5-STEP RISK PROCEDURE

   ┌─────────────────────────────────────────────────────────────────────────┐
   │                                                                         │
   │      ┌───────────────┐                  ┌───────────────┐               │
   │      │   1. IDENTIFY │ ───────────────► │   2. ASSESS   │               │
   │      │ • Context     │                  │ • Estimate    │               │
   │      │ • Risks       │                  │ • Evaluate    │               │
   │      └───────┬───────┘                  └───────┬───────┘               │
   │              │                                  │                       │
   │              ▼                                  ▼                       │
   │     ┌──────────────────────────────────────────────────┐                │
   │     │                 5. COMMUNICATE                   │                │
   │     │  Continuous reporting across all steps via:      │                │
   │     │  • Checkpoints  • Highlights  • End Stage        │                │
   │     │  • Exception Reports  • End Project Reviews      │                │
   │     └──────────────────────────────────────────────────┘                │
   │              ▲                                  ▲                       │
   │              │                                  │                       │
   │      ┌───────┴───────┐                  ┌───────┴───────┐               │
   │      │ 4. IMPLEMENT  │ ◄─────────────── │   3. PLAN     │               │
   │      │ • Authorize   │                  │ • Select      │               │
   │      │ • Assign & Mon│                  │   Responses   │               │
   │      └───────────────┘                  └───────────────┘               │
   │                                                                         │
   └─────────────────────────────────────────────────────────────────────────┘

• Sequential Execution: Steps 1 through 4 proceed in logical sequence: you cannot assess risks until you identify them; you cannot plan responses until you assess their severity; and you cannot implement responses until they are planned and authorized.
• Continuous Communication: Step 5 (Communicate) does not sit at the end of a chronological conveyor belt. It operates continuously and concurrently across all four other steps, ensuring that stakeholders, suppliers, and governance boards are informed of changes in risk exposure in real time.

---

2. Step 1: Identify — Context & Risks

The Identify step consists of two sequential activities: Identify Context and Identify Risks.

2.1 Identify Context

Before hunting for individual risks, the project team must understand the operational, commercial, and organizational environment in which the project operates:

• Corporate Risk Policies: What enterprise risk management standards (e.g., ISO 31000) or regulatory guidelines govern the organization?
• Commercial Environment: What contractual obligations, fixed-price vendor arrangements, penalty clauses, or multi-supplier dependencies exist?
• Project Constraints: What are the non-negotiable boundaries regarding delivery dates, budget caps, quality baselines, and carbon emission targets?
• The Risk Management Approach: How has the project tailored its risk management tools, scoring scales, and reporting cadences?

2.2 Identify Risks & The Risk Grammar (Cause-Event-Effect)

A foundational requirement in PRINCE2 7 is expressing risks using the formal Cause-Event-Effect formulation (also known as the Risk Grammar). Unstructured, sloppy risk logging—such as writing "The risk is software bugs" or "The risk is supplier delay"—is strictly rejected on the Practitioner exam.

                   THE THREE-PART RISK SYNTAX ARCHITECTURE

   ┌────────────────┐      ┌─────────────────┐      ┌─────────────────┐
   │   1. CAUSE     │  ──► │    2. EVENT     │  ──► │   3. EFFECT     │
   ├────────────────┤      ├─────────────────┤      ├─────────────────┤
   │ The present,   │      │ The uncertain   │      │ The measurable  │
   │ observable fact│      │ occurrence that │      │ business impact │
   │ or source of   │      │ may or may not  │      │ on project targets│
   │ risk           │      │ materialize     │      │ if event occurs │
   │ (Because of...)│      │ (There is a...) │      │ (Resulting in..)│
   └────────────────┘      └─────────────────┘      └─────────────────┘

1. Cause (Source / Trigger / Fact): A present factual condition, constraint, or environmental truth (e.g., "Because the development team is adopting a newly released, unproven cloud architecture framework...").
2. Event (Uncertain Occurrence): The specific uncertainty that may or may not happen (e.g., "...there is a risk that unexpected API integration incompatibilities will arise during database linking...").
3. Effect (Consequence / Impact): The measurable business damage or benefit to project performance targets (e.g., "...which will result in a 3-week delay to the Stage 2 milestone and an estimated $45,000 cost overrun for specialized remediation consultants.").

Comparison Table: Defective vs. Rigorous Risk Formulations

2.3 Risk Identification Techniques

PRINCE2 7 advocates a multi-method identification approach to overcome blind spots and cognitive biases:

• Prompt Lists: Structured taxonomic checklists that prompt teams to consider broad risk categories, such as PESTLE (Political, Economic, Sociological, Technological, Legal, Environmental) or TECOP (Technical, Environmental, Commercial, Operational, Political).
• Lessons Log Review: Examining the Lessons Log from previous projects to identify recurring pitfalls, vendor failure modes, or overlooked regulatory barriers (embodying the Learn from Experience principle).
• Risk Workshops & Brainstorming: Structured, cross-functional sessions engaging users, technical suppliers, and business leaders to uncover hidden systemic dependencies.
• Horizon Scanning: Continuous surveillance of external markets, emerging technologies, regulatory changes, and geopolitical events that could affect the project.
• SWOT Analysis: Identifying internal Strengths and Weaknesses alongside external Opportunities and Threats.
• Cause and Effect Diagrams: Tracing a potential event back through its contributing causes, which is what makes a well-formed cause-event-effect entry possible in the first place.
• Pre-mortem: A technique PRINCE2 7 names explicitly. The team looks backwards from a future point at which the objectives should have been achieved, painting a scenario of either success or failure, then analyses the steps that led to that result. Working backwards from an imagined outcome surfaces threats and opportunities that forward-looking brainstorming reliably misses, because it removes the social cost of predicting failure.
• The Swiss Cheese Model: Also named in the manual, and used at the control end rather than the identification end. It models a risk as having to pass through several layers of control, each with holes; the risk only occurs when the holes in every layer line up. Its practical value is in asking whether the controls in place are sufficient — a single strong control with one large gap is weaker than three modest, independent controls whose gaps do not coincide.
• Use of Data: Data analytics over comparable projects, products, or tasks gives a better read on the project's predisposition to particular risks, and therefore on probability, impact, and priority. Robotic process automation may be used to automate parts of the risk procedure — assigning actions, monitoring, reporting, and escalation.

[!EXAM WATCHPOINT] The pre-mortem and Swiss cheese model appear in the manual as named supporting techniques (sections 9.3.2.4 and 9.3.2.5). Distinguish their purpose: a pre-mortem identifies risks; the Swiss cheese model tests whether the responses you have chosen are enough. A scenario asking "how should the team check that the mitigations are adequate?" points to Swiss cheese, not to another brainstorming round.

---

3. Step 2: Assess — Estimate & Evaluate

Once risks are identified, they must be assessed. In PRINCE2 7, assessment is executed in two distinct sub-steps: Estimate (assessing single risks) and Evaluate (assessing overall project risk exposure).

                      STEP 2: THE TWO PHASES OF RISK ASSESSMENT

   PHASE 2A: ESTIMATE (Individual Level)     PHASE 2B: EVALUATE (Project Level)
   ┌───────────────────────────────────┐     ┌───────────────────────────────────┐
   │ Assesses individual risks on:     │     │ Assesses collective exposure on:  │
   │ • Probability (Likelihood)        │ ──► │ • Aggregated Monetary Exposure    │
   │ • Impact (across 7 targets)       │     │ • Summary Risk Profile (Grid)     │
   │ • Proximity (Timeframe of event)  │     │ • Exposure vs. Risk Tolerances    │
   │ • Expected Value (P × I)          │     │ • Monte Carlo Simulation Analysis │
   └───────────────────────────────────┘     └───────────────────────────────────┘

3.1 Phase 2a: Estimate (Individual Risk Analysis)

Estimating evaluates the characteristics of an individual threat or opportunity:

1. Probability

The likelihood that the uncertain event will materialize. The Risk Management Approach defines the scoring scale (e.g., qualitative: Very Low, Low, Medium, High, Very High; or quantitative percentages: 10%, 30%, 50%, 70%, 90%).

2. Impact

The estimated magnitude of effect on project objectives if the event occurs. Impact must be evaluated across the seven aspects of project performance:

• Financial: Budget overruns or cost savings.
• Time: Schedule milestones and critical path slippage.
• Quality: Defect rates and performance degradation.
• Scope: Descoping of products or feature additions.
• Benefits: Damage to NPV, ROI, or strategic utility in the Business Case.
• Sustainability: Excessive carbon emissions, material waste, or environmental harm.
• Risk: Triggering cascading secondary risks.

3. Proximity

Proximity is the anticipated timeframe or date by which the risk event is expected to occur (e.g., Imminent: within 2 weeks; Current Stage: within 2 months; Next Stage: 3–6 months; Post-Project: during operational lifecycle).

[!CRITICAL EXAM PRINCIPLE: PROXIMITY VS. IMPACT] On the Practitioner exam, candidates are frequently tricked into prioritizing risks based solely on financial impact. This is wrong. A $500,000 threat with a proximity of 18 months does not require immediate operational resources. Conversely, an $80,000 threat with an imminent proximity of 5 days requires immediate response planning. Proximity dictates the urgency of action.

4. Expected Value (Expected Monetary Value - EMV)

For financial impacts, Expected Value converts probabilistic uncertainty into a tangible mathematical figure:

$\text{Expected Value } (EV) = \text{Probability } (P) \times \text{Financial Impact } (I)$

Example: If a supplier failure has a 30% probability ($0.30$) and a financial impact of $150,000, the Expected Monetary Value is:

$EV = 0.30 \times \$150,000 = \$45,000$

Calculating EMV allows the project team to size risk budgets objectively and rank threats mathematically.

3.2 Phase 2b: Evaluate (Aggregated Project Risk Exposure)

While estimating looks at risks in isolation, Evaluate aggregates all individual threats and opportunities to measure the project's total risk exposure against approved Risk Tolerances.

The Probability-Impact Grid (Risk Matrix)

A Probability-Impact Grid maps threats and opportunities onto a matrix. The Risk Management Approach establishes a Risk Tolerance Line across the grid:

                     PROBABILITY - IMPACT GRID & TOLERANCE LINE

   PROBABILITY
   ▲
   │ Very High │   (Low)   │  (Medium) │  [ HIGH ] │ [CRITICAL]│ [CRITICAL]│
   │ High      │   (Low)   │  (Medium) │  [ HIGH ] │ [ HIGH ]  │ [CRITICAL]│
   │ Medium    │  (V.Low)  │   (Low)   │ ══════════╪═══════════╪═══════════│ ◄── RISK TOLERANCE LINE
   │ Low       │  (V.Low)  │  (V.Low)  │   (Low)   │  (Medium) │  (Medium) │     (Breach triggers
   │ Very Low  │  (V.Low)  │  (V.Low)  │  (V.Low)  │   (Low)   │   (Low)   │      Exception Report)
   └───────────┴───────────┴───────────┴───────────┴───────────┴───────────►
                 Very Low       Low       Medium       High      Very High
                                       IMPACT

• Risks falling above the tolerance line are intolerable; the Project Manager cannot manage them autonomously. They require aggressive avoidance, mitigation, or formal escalation via an Exception Report.
• Risks falling below the tolerance line are acceptable and can be managed within delegated operational tolerances.

The Summary Risk Profile

A Summary Risk Profile provides the Project Board with a graphical snapshot of all open project risks. It plots risks dynamically across stages, enabling executive leaders to assess whether the cumulative exposure threatens the overall project Business Case.

Aggregated Exposure & Tolerance Breaches

Even if every individual threat sits below the tolerance line, their combined expected monetary value may exceed the total stage or project risk tolerance. For example, if a stage has ten threats, each with an expected value of $15,000 (individual impacts well within tolerance), the aggregated exposure is $150,000. If the stage risk tolerance is $100,000, a formal risk tolerance breach has occurred, mandating an Exception Report.

---

4. Step 3: Plan — Selecting Appropriate Responses

The Plan step focuses on preparing balanced, cost-effective responses to mitigate threats and maximize opportunities.

4.1 Proportionality & Cost-Benefit Analysis

Every proposed risk response must be evaluated for commercial viability. In PRINCE2 7, the golden rule of risk planning is proportionality:

$\text{Cost of Risk Response} < \text{Expected Value of the Risk (P } \times \text{ I)}$

If a project faces a 10% chance of experiencing a $50,000 component failure (Expected Value = $5,000), spending $25,000 on a secondary backup system is irrational and bad management. The cost of the cure must never exceed the severity of the disease.

4.2 Secondary Risks & Residual Risks

During the Plan step, the project team must rigorously analyze two downstream consequences:

1. Secondary Risks: New risks that arise as a direct consequence of implementing a risk response. Example: To reduce the threat of server overheating, the team installs liquid cooling (Response); this creates a secondary risk of coolant leakage short-circuiting electrical components.
2. Residual Risks: The remaining risk exposure that persists after the response has been executed. No response eliminates 100% of uncertainty. The residual risk must fall comfortably within the project's risk tolerance.

---

5. Step 4: Implement — Authorize, Allocate & Monitor

Planning a response is useless without disciplined execution. The Implement step turns plans into operational reality across three sub-actions:

                     STEP 4: IMPLEMENTATION GOVERNANCE

   ┌────────────────────┐      ┌────────────────────┐      ┌────────────────────┐
   │ 1. AUTHORIZE       │  ──► │ 2. ALLOCATE ROLES  │  ──► │ 3. MONITOR & TRACK │
   ├────────────────────┤      ├────────────────────┤      ├────────────────────┤
   │ Project Board / PM │      │ Assign named       │      │ Track risk triggers│
   │ approves response  │      │ Risk Owner &       │      │ & early warnings;  │
   │ budget & actions   │      │ Risk Action Owner      │      │ verify efficacy│
   └────────────────────┘      └────────────────────┘      └────────────────────┘

1. Authorize Responses: Confirming funding and commercial approval. If a response requires funding from the Risk Budget, formal authorization must be obtained according to the rules baselined in the Risk Management Approach.
2. Allocate Roles: Formally assigning a named Risk Owner (to oversee and monitor the risk strategy) and a named Risk Action Owner (to carry out specific operational tasks).
3. Monitor Effectiveness: Continuously tracking early warning indicators (risk triggers) to determine whether the response is working, whether probability and impact have changed, or whether secondary risks are materializing.

---

6. Step 5: Communicate — Continuous Bidirectional Reporting

Step 5 is the communication conduit that links all risk activities to decision-makers across the project organization.

                 PRINCE2 RISK COMMUNICATION TOUCHPOINTS
   
   MANAGEMENT LAYER      PRODUCT               RISK COMMUNICATION CONTENT
   
   Directing             Highlight Report      Summary of top threats/opportunities,
   (Project Board)       (Time-driven)         changes in exposure, & tolerance tracking
                         ─────────────────────────────────────────────────────────────
                         End Stage Report      Review of stage risk management,
                         (Event-driven)        residual risks, & next stage profile
                         ─────────────────────────────────────────────────────────────
                         Exception Report      Immediate escalation when project or
                         (Event-driven)        stage risk tolerance is forecast breached
         ▲
         │
   Managing              Checkpoint Report     Team-level risks identified in Work
   (Project Manager)     (Time-driven)         Packages; status of assigned actions
         ▲
         │
   Delivering            Daily Log /           Informal team concerns, technical
   (Team Managers)       Team Meetings         anomalies, & supplier delivery alerts

Risk Reporting Cadence Across Core Management Products

---

7. Practical Practitioner Scenario Evaluations

Scenario A: Poor Risk Formulation (Muddling Cause and Effect)

On a smart metering rollout project, a field installation technician logs an entry in the project risk tracking sheet: "The risk is that smart meters fail customer security inspections." The Project Manager accepts the entry, assigns it a High probability, and allocates $30,000 to purchase external PR crisis management consulting.

Practitioner Evaluation:

• Governance Flaw: The Project Manager accepted a severely defective risk formulation that fails the Cause-Event-Effect rule.
• Impact: Stating "meters fail inspection" describes a potential event, but gives zero indication of the underlying root cause. Is the failure caused by firmware encryption bugs, poor physical tamper seals, or untrained field technicians? Without identifying the cause, the Project Manager wasted $30,000 on PR consulting (an inappropriate effect response) while doing nothing to fix the actual engineering defect.
• Correct PRINCE2 Action: The Project Manager must reject the entry and instruct the team to apply the three-part syntax: "Because firmware developers used an uncertified encryption protocol [Cause], there is a risk that meters will fail national cyber-security testing [Event], resulting in regulatory stop-work orders and $200,000 in hardware recall costs [Effect]." With this formulation, the correct response is immediately obvious: recode the firmware using certified cryptographic libraries.

Scenario B: Misinterpreting Proximity in Resource Prioritization

During Stage 1 of a commercial office development, the Project Manager reviews two threats in the Risk Register. Threat Alpha involves an estimated $400,000 cost penalty if local utility companies delay the permanent power substation hookup, which is scheduled 14 months away in Stage 4. Threat Beta involves an estimated $35,000 cost penalty if ground contamination is encountered during soil excavation scheduled to start in 7 days. Facing severe engineering workload constraints, the Project Manager directs the team to focus 100% of their time on analyzing Threat Alpha, leaving Threat Beta unaddressed.

Practitioner Evaluation:

• Governance Flaw: The Project Manager made a classic scheduling error by prioritizing magnitude of impact over proximity.
• Impact: While Threat Alpha represents a larger financial figure, its proximity is distant (14 months). The project has ample time to plan for Threat Alpha in future stage boundaries. Threat Beta, however, has an imminent proximity of 7 days. Failing to develop response plans for Threat Beta immediately means the window to mitigate or test soil conditions will close, guaranteeing project disruption.
• Correct PRINCE2 Action: The Project Manager must prioritize Threat Beta due to its imminent proximity, authorizing immediate soil testing, while scheduling Threat Alpha for detailed analysis during the Stage 3 boundary review.

Scenario C: Failing to Escalate an Aggregate Risk Tolerance Breach

A medical device clinical trial project operates with a Project Board-approved stage risk tolerance of $120,000 Expected Monetary Value. During Stage 2, eight separate technical threats are identified. The Project Manager assesses each threat individually: each has an EMV between $18,000 and $25,000. Because no single threat exceeds the $120,000 tolerance boundary, the Project Manager manages them quietly. However, the cumulative expected monetary value of the eight threats is $168,000 ($48,000 above the approved stage tolerance).

Practitioner Evaluation:

• Governance Flaw: The Project Manager failed to execute the Evaluate phase of the Assess step and committed a serious breach of the Manage by Exception principle.
• Impact: Risk tolerance applies to aggregated project risk exposure as well as individual risks. Managing individual threats in isolation blinded the project team to the reality that cumulative risk exposure had breached the Project Board's delegated risk threshold.
• Correct PRINCE2 Action: During the Evaluate phase, the Project Manager must calculate aggregated risk exposure. Upon discovering that total EMV ($168,000) exceeded the approved tolerance ($120,000), the Project Manager was obligated to submit an Exception Report to the Project Board immediately.

---

8. Practitioner Exam Pitfalls & Governance Traps

• Trap 1: Believing Communicate is the Final Step: On the Practitioner exam, questions will depict communication as something done only after responses are implemented. In PRINCE2, Communicate is continuous and bidirectional, connecting all steps simultaneously.
• Trap 2: Ignoring Proximity in Response Timelines: Exam questions love tempting candidates to prioritize a massive distant threat over a moderate imminent threat. Remember: Proximity determines urgency of action.
• Trap 3: Evaluating Risks in Isolation Only: Assessing single risks (Estimate) is only half the battle. You must evaluate aggregated project risk exposure against tolerances (Evaluate). Breaching aggregate tolerance requires an Exception Report.
• Trap 4: Confusing Causes with Effects: A cause is an existing factual situation (e.g., "inexperienced staff"). An effect is the measurable impact on project performance targets (e.g., "$20,000 rework cost"). The exam frequently tests whether candidates can identify defective risk formulations.
• Trap 5: Disproportionate Response Spending: A risk response whose implementation cost exceeds the Expected Monetary Value of the threat fails the business justification test and is defective under PRINCE2 rules.