Study guide
10.3 Risk Registers, Ownership, and Risk vs Issue Distinction
APM Project Fundamentals Qualification PFQ
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Project Management & Operating Environment
1.1 Projects vs Business as Usual (BAU) 1.2 Programmes, Portfolios, and Strategic Alignment 1.3 Operating Environment and PESTLE Analysis
2 Chapter 2: Project Life Cycles
2.1 Linear Project Life Cycles and Phase Gates 2.2 Iterative and Hybrid Life Cycles 2.3 Extended Life Cycles, Handover, and Benefits Realization
3 Chapter 3: Roles, Governance & Organization
3.1 The Project Sponsor and Governance Board 3.2 The Project Manager and Project Team 3.3 Users, Product Owners, and the Project Management Office (PMO)
4 Chapter 4: Business Case, Benefits & Stakeholders
4.1 Purpose, Content, and Roles in Developing the Business Case 4.2 Benefits Management and Value Tracking 4.3 Stakeholder Analysis and Engagement Matrix
5 Chapter 5: Project Management Plan & Estimating
5.1 Project Management Plan (PMP) and Deployment Baselines 5.2 Estimating Methods and the Estimating Funnel 5.3 Project Reporting, Variance Tracking, and Success Criteria
6 Chapter 6: Scope Definition & Breakdown Structures
6.1 Scope Management Principles in Linear vs Iterative Delivery 6.2 Product Breakdown Structures (PBS) and Work Breakdown Structures (WBS) 6.3 OBS, CBS, and the Responsibility Assignment Matrix (RACI)
7 Chapter 7: Change Control & Configuration Management
7.1 Requirements Definition and Acceptance Criteria 7.2 The Change Control Process and Impact Assessment 7.3 Configuration Management and Version Verification
8 Chapter 8: Schedule Planning & Critical Path
8.1 Scheduling Principles, Gantt Charts, and Milestones 8.2 Critical Path Analysis, Dependencies, and Float 8.3 Time Boxing and Iterative Schedule Control
9 Chapter 9: Resource Optimization & Procurement
9.1 Resource Optimization: Allocation, Smoothing, and Levelling 9.2 Procurement Strategy and Supplier Selection 9.3 Contract Types and Supplier Reimbursement Methods
10 Chapter 10: Risk and Issue Management
10.1 Principles of Risk Management and the Risk Process 10.2 Threat and Opportunity Response Strategies 10.3 Risk Registers, Ownership, and Risk vs Issue Distinction 10.4 Issue Management Process, Escalation, and Governance
11 Chapter 11: Quality Management & Project Reviews
11.1 Quality Definitions, Management, and Quality Planning 11.2 Quality Assurance vs Quality Control 11.3 Project Reviews, Decision Gates, and Audits
12 Chapter 12: Project Communication Management
12.1 Principles of Project Communication and Communication Models 12.2 Communication Methods: Advantages, Limitations, and Barriers 12.3 Developing and Benefiting from a Project Communication Plan
13 Chapter 13: Leadership, Teams & Conflict
13.1 Leadership Styles and Influencing Team Performance 13.2 Team Development Models: Tuckman and Belbin 13.3 Team Challenges, Conflict Resolution, and Collaboration
10.3 Risk Registers, Ownership, and Risk vs Issue Distinction
Key Takeaways Explain This Topic AI
BoK7 defines a risk register as a document listing identified risk events and their corresponding planned responses, used interchangeably with risk log or risk repository; in practice it also records impact, ownership and the actions taken.
APM standard risk descriptions follow a structured causal syntax: 'Because of [Cause], [Event] may occur, which will lead to [Effect]'.
The Risk Owner holds ultimate accountability for managing, monitoring, and funding the assigned risk, while the Risk Actionee is delegated to execute specific mitigation tasks.
BoK7 defines an issue as a problem that is now breaching, or is about to breach, delegated tolerances for work on a project or programme, and states that issues require support from the sponsor to agree a resolution.
When an identified threat event actually occurs it ceases to be a risk: the register entry is closed as materialised and the problem is managed through the issue log, with the sponsor supporting the resolution.
Last updated: September 2026
10.3 Risk Registers, Ownership, and Risk vs Issue Distinction
Definition (APM BoK7 glossary): A risk register is a document listing identified risk events and their corresponding planned responses. Used interchangeably with risk log or risk repository. BoK7 (4.3.3) adds that "a risk register is used to document risks, analysis and responses, and to assign clear ownership of actions" — so when a question asks for the purpose of a risk register, the answer APM expects is a record of the risks, their impact and the actions taken to manage them.
An issue is a problem that is now breaching, or is about to breach, delegated tolerances for work on a project or programme. Issues require support from the sponsor to agree a resolution. Note the second sentence: sponsor involvement is part of the definition, not an optional escalation path.
Effective risk management demands rigorous record-keeping and unambiguous accountability. Without a centralized, shared record of uncertainties, risk intelligence remains trapped in individual team members' heads, leading to blind spots and uncoordinated responses. The primary vehicle for capturing and governing project uncertainties is the Risk Register .
Equally vital for any project professional is mastering the boundary between Risks and Issues . Candidates sitting the APM Project Fundamentals Qualification (PFQ) frequently encounter questions testing this core distinction. Confusing a risk with an issue undermines project governance: treating a current operational crisis as an uncertain future possibility delays urgent action, while treating an uncertain future threat as an immediate crisis results in wasteful panic.
The Project Risk Register (Risk Log)
The Risk Register is a live management document established during the Initiate stage and continuously maintained across every phase of the project lifecycle. It serves as the project's single source of truth for risk identification, assessment, ownership, and response tracking.
Essential Fields in an APM-Compliant Risk Register
BoK7’s definition is deliberately short — identified risk events and their planned responses — but in practice a register carries more. While organisations adapt templates to suit their maturity, the fields below are those a robust risk register captures:
Risk Identifier (ID): A unique alphanumeric reference code (e.g., RSK-001 , RSK-042 ) used for cross-referencing in reports and meeting minutes.
Date Raised & Originator: When the risk was formally logged and who identified it.
Risk Category (Source): Classification by domain (e.g., Commercial, Technical, Environmental, Legal, Operational, Safety) to assist in trend analysis.
Structured Risk Description (Cause-Event-Effect): A precise narrative separating the root cause, uncertain event, and resulting impact.
Inherent (Pre-Mitigation) Scores: Initial qualitative ratings for Probability (P) and Impact (I), typically on a 1-to-5 scale, yielding an inherent Risk Exposure score ( P × I P \times I P × I ).
Assigned Risk Owner: A named individual with overall accountability for managing the risk.
Mitigation / Response Strategy & Action Plan: The chosen strategy (Avoid, Reduce, Transfer, Accept / Exploit, Enhance, Share, Reject) and specific, concrete steps to be taken.
Assigned Risk Actionee: The specific individual delegated to execute the practical mitigation actions.
Residual (Post-Mitigation) Scores: The forecast Probability and Impact scores that will remain after mitigation actions are successfully implemented.
Status & Target Review Date: The operational state of the risk (e.g., Identified, Assessing, Mitigating, Closed, Materialized) and the deadline for the next review. +-------------------------------------------------------------------------------------------------------------------------+
| TYPICAL RISK REGISTER EXTRACT |
+----+-------------+---------------------------------------+-----------+---------+------------+------------+-------+------+
| ID | Category | Risk Description (Cause-Event-Effect) | Inherent | Owner | Strategy | Actionee | Resid | Status|
| | | | P x I = E | | & Action | | P x I | |
+----+-------------+---------------------------------------+-----------+---------+------------+------------+-------+------+
| 01 | Commercial | Because supplier faces cash crunch, | 4 x 4 =16 | J. Smith| Transfer: | T. Brown | 2 x 2 | Open |
- | | | steel delivery may be delayed 3 wks, | (RED) | (Procure| Fixed-cost | (Contract | = 4 | |
- | | | causing £60k site idle overheads. | | Lead) | liquidated | Specialist)|(GREEN)| |
- | | | | | | damages. | | | |
+----+-------------+---------------------------------------+-----------+---------+------------+------------+-------+------+
The Cause-Event-Effect Formulation
A frequent pitfall in project management is logging vague statements in the Risk Register, such as "Weather risk" or "Budget risk" . These are not actionable risks; they fail to distinguish between facts that already exist and uncertainties that might happen.
To enforce clarity, APM recommends the Cause-Event-Effect structured syntax : "Because of [ C a u s e ] , [ E v e n t ] may occur, which will lead to [ E f f e c t ] ." \text{"Because of } [\mathbf{Cause}]\text{, } [\mathbf{Event}]\text{ may occur, which will lead to } [\mathbf{Effect}]\text{."} "Because of [ Cause ] , [ Event ] may occur, which will lead to [ Effect ] ."
Cause (The Existing Fact): A definite, present condition or operational context that creates vulnerability (e.g., "Because the development team has no prior experience with the new cloud database..." ).
Event (The Uncertainty): The uncertain occurrence that may or may not happen in the future ( 0 % < P r o b a b i l i t y < 100 % 0\% < Probability < 100\% 0% < P ro babi l i t y < 100% ) (e.g., "...data migration errors may occur during cutover..." ).
Effect (The Impact on Objectives): The tangible consequence on time, cost, scope, or quality should the event happen (e.g., "...which will lead to a 5-day schedule delay and £25,000 in emergency contractor support costs." ).
Separating cause from event prevents teams from trying to "mitigate" unchangeable facts, allowing them to focus countermeasures directly on stopping the event or cushioning the effect.
Roles and Accountabilities: Risk Owner vs. Risk Actionee
A critical distinction in APM PFQ Assessment Criterion 7.4 is the division of responsibility between the Risk Owner and the Risk Actionee :
1. The Risk Owner (Accountability)
The Risk Owner is a single named individual assigned formal accountability for managing, monitoring, and controlling the assigned risk.
Key Responsibilities:
Evaluating and recommending the appropriate response strategy (e.g., choosing whether to mitigate or transfer).
Monitoring the risk environment for early-warning triggers.
Ensuring that adequate resources and funding are deployed for response actions.
Regularly updating the Risk Register and reporting status to the Project Manager and governance boards.
Golden Rule: Accountability cannot be delegated. Even if a team of twenty technicians works on mitigating a risk, the Risk Owner remains solely accountable to the Project Manager for the outcome.
2. The Risk Actionee (Execution)
The Risk Actionee is the specific person or technical specialist delegated by the Risk Owner to execute practical, tactical mitigation tasks.
Key Responsibilities:
Carrying out day-to-day mitigation work (e.g., configuring firewall software, conducting non-destructive metal testing, drafting an insurance rider).
Reporting progress, hurdles, and completion milestones back to the Risk Owner.
Summary of Distinction: The Risk Owner has accountability for the risk; the Risk Actionee has responsibility for executing specific tasks. A Risk Owner may also act as the Risk Actionee on smaller projects, but on complex projects, the roles are typically divided.
The Probability-Impact (P-I) Matrix and Risk Exposure
To prioritize risks without getting bogged down in complex mathematics, project managers utilize the Probability-Impact (P-I) Matrix (often a 5 × 5 5 \times 5 5 × 5 or 3 × 3 3 \times 3 3 × 3 grid).
The vertical axis plots Probability (e.g., 1 = Very Low to 5 = Very High).
The horizontal axis plots Impact (e.g., 1 = Negligible to 5 = Critical).
The intersecting score represents the Risk Exposure ( P × I P \times I P × I ).
The matrix establishes clear visual governance thresholds using a Red-Amber-Green (RAG) convention:
Red Risks (High Priority / Extreme Exposure): Severe threats that threaten project viability. Demands mandatory proactive mitigation, significant management attention, and immediate escalation to executive sponsors.
Amber Risks (Medium Priority / Moderate Exposure): Meaningful uncertainties that require planned countermeasures and regular monitoring during periodic risk reviews.
Green Risks (Low Priority / Low Exposure): Minor operational uncertainties placed on a "watch list". Reviewed periodically to ensure their probability or impact has not escalated.
The Fundamental Distinction Between a Risk and an Issue
The boundary between a Risk and an Issue is one of the most vital principles in project management (APM PFQ AC 7.7). Misunderstanding this distinction leads to governance failure.
The Core Definitions
Risk: An uncertain event or set of events situated in the future ( 0 % < P r o b a b i l i t y < 100 % 0\% < Probability < 100\% 0% < P ro babi l i t y < 100% ). It might happen, or it might not. Risk management is fundamentally proactive —identifying threats in advance to prevent them, and identifying opportunities to capture them.
Issue: BoK7 defines an issue as a problem that is now breaching, or is about to breach, delegated tolerances for work on a project or programme , adding that issues require support from the sponsor to agree a resolution. In other words an issue is a certain event — it is happening, or it is definitely about to — which is exactly the difference the exam tests. BoK7 (4.3.5) also separates issues from routine problems: "issues are differentiated from problems that are dealt with on a day-to-day basis by the project manager and team". +-----------------------------------------------------------------------------------+
- | THE RISK VS ISSUE DIVIDE |
- +-----------------------------------------------------------------------------------+
- | DIMENSION | PROJECT RISK | PROJECT ISSUE |
- +---------------------+--------------------------------+----------------------------+
- | Certainty | Uncertain — it may or may not happen | Certain — it is happening, or will definitely happen |
- | Temporal Focus | Future (What might happen) | Present (Happening now) |
- | Management Stance | Proactive (Anticipate/Prevent) | Reactive (Resolve/Recover) |
- | Governing Log | Risk Register | Issue Log (Issue Register) |
- | Evaluation Metric | Probability and Impact | Actual Consequence/Urgency |
- | Key Response Focus | Avoid, Reduce, Transfer, Accept| Escalation, Fix, Recovery |
- +-----------------------------------------------------------------------------------+
- The Transition: How a Risk Becomes an Issue
BoK7 notes that "issues may develop when particular risks or groups of risks actually occur", and that issues happening now "may also be causes of new risks, or result in assessment of risk likelihood and/or size of impact to change". When an identified threat event materialises during execution it undergoes an immediate formal transition:
The uncertainty collapses to certainty: the event is no longer potential, it is real.
The event ceases to be a risk. Pre-mitigation risk planning is terminated.
The item is updated in the Risk Register as "Materialized" and formally closed.
The problem is logged immediately in the Issue Log (or Issue Register).
If the impact of the materialized event breaches or threatens to breach delegated project tolerances, the Project Manager immediately escalates the matter to the Project Sponsor via an Exception Report .