By Rahul Dhakate · PMP Certified · May 2026 · learnxyz.in
The Risk Register and the Risk Report are two distinct documents in PMI’s risk management framework. They are related — both deal with project risks — but they serve entirely different purposes, contain different information, and are used by different audiences.
This is a distinction the PMP exam tests specifically, and it is one that trips up a surprising number of candidates who understand risk management in practice but have not been precise about the terminology.
Contents
Risk Register vs Risk Report in PMP — What’s the Difference?
A Real Risk That Nearly Derailed a Project
What the Risk Register Contains
The Four Risk Response Strategies for Threats.
Risk Opportunities — The Other Side of Risk.
How These Documents Are Tested on the PMP Exam.
Pattern 1: Document Identification
Pattern 2: When to Create Each
Pattern 3: Risk Response Selection
Pattern 4: Risk Owner Responsibility
Let me start with a real example that illustrates why both documents exist and why each matters.
A Real Risk That Nearly Derailed a Project
At Valethi Technologies, we were delivering an eCommerce platform for a client with a distributed team — developers in India working on React and C# components, and the API team based in Barcelona, Spain. The platform architecture depended heavily on APIs delivered by the Barcelona team — without those APIs, our React developers could not complete the front-end integrations, and our C# team could not finalise the backend services.
The risk we identified early: API delivery dependency on the Barcelona team. If their APIs were delayed, it would create a cascading blockage across virtually every other workstream. React development would stall. C# development would stall. Integration testing could not begin. The project timeline would collapse.
This risk was logged in the Risk Register with a high probability and high impact rating. It had a specific owner, a mitigation strategy (establish weekly API delivery checkpoints with the Barcelona team, create stub APIs to allow parallel development), and a contingency response (escalate to client programme manager if API milestones were missed by more than five days).
The Risk Report, meanwhile, communicated a summarised version of this risk to project stakeholders — the client’s senior management and the programme manager — in a format they could act on at a governance level without needing to read the detailed register.
The APIs were eventually delayed by the Barcelona team. The mitigation strategy — stub APIs for parallel development — was activated immediately, and the escalation path was used when the delay exceeded five days. The project was delivered on time despite the delay because the risk had been planned for properly. That is what a good risk management process looks like in practice.
What is the Risk Register?
The Risk Register is a project document that records the details of all identified risks throughout the project lifecycle. It is a working document — maintained and updated continuously by the project manager and the project team from the earliest stages of planning through to project close.
What the Risk Register Contains
- Risk ID: A unique identifier for each risk
- Risk description: A clear statement of the risk event and its potential cause
- Risk category: The type of risk (technical, schedule, resource, external, etc.)
- Probability: The likelihood of the risk occurring (often rated as Low / Medium / High or as a percentage)
- Impact: The effect on the project if the risk occurs (rated similarly)
- Risk score / priority: Typically Probability × Impact, used to prioritise which risks need the most attention
- Risk owner: The person responsible for monitoring the risk and implementing responses
- Risk response strategy: How the team plans to deal with the risk — Avoid, Transfer, Mitigate, or Accept (for threats); Exploit, Share, Enhance, or Accept (for opportunities)
- Contingency response: What the team will do if the risk actually occurs
- Current status: Whether the risk is open, closed, materialised, or retired
The Risk Register is a detailed, operational document. It is owned by the project manager and used by the project team. It is updated throughout the project — risks are added as they are identified, updated as their probability or impact changes, and closed when they are resolved or no longer relevant.
What is the Risk Report?
The Risk Report is a project document that provides a summary-level view of overall project risk and the status of individual risk responses, intended for stakeholders and governance audiences.
Where the Risk Register is detailed and operational, the Risk Report is summarised and strategic. It answers the question: what does project leadership need to know about risk right now?
What the Risk Report Contains
- Overall project risk assessment: Is the project’s overall risk level Low, Medium, or High? Is it trending better or worse than last period?
- Summary of top risks: The highest-priority risks from the register, presented in a concise format appropriate for executive review
- Risk response effectiveness: Are the current mitigation and contingency strategies working?
- Risk trends: How has the overall risk profile changed since the last reporting period?
- Newly identified risks: Any significant new risks identified since the last report
- Key decisions or escalations required: Any risks that require stakeholder action or governance-level decisions
The Risk Report is prepared periodically — typically aligned with project reporting cycles — and is distributed to project sponsors, steering committees, client representatives, and other governance stakeholders. It is not a document the project team works from day-to-day; it is a communication document for people who need a risk overview without the full detail of the register.
Side-by-Side Comparison
| Factor | Risk Register | Risk Report |
| Purpose | Record and manage all risks in detail | Communicate overall risk status to stakeholders |
| Audience | Project manager and project team | Sponsors, steering committee, governance |
| Level of detail | High — full details of every risk | Summary — top risks and overall assessment |
| Update frequency | Continuously throughout project | Periodically — aligned with reporting cycles |
| Created during | Risk identification (early planning) | Risk monitoring and control (ongoing) |
| Who owns it | Project Manager | Project Manager (for stakeholder distribution) |
| Contains risk scores? | Yes — full probability × impact matrix | Summary ratings only — not the full matrix |
| Contains response plans? | Yes — full mitigation and contingency detail | Summary of response effectiveness |
| Format | Detailed spreadsheet or table | Narrative report with summary tables |
The Four Risk Response Strategies for Threats
The Risk Register documents your response strategy for each risk. The PMP exam tests whether you know which strategy is appropriate in which situation. For threats (negative risks), the four strategies are:
| Strategy | What It Means | When to Use It |
| Avoid | Change the project plan to eliminate the risk entirely | When the risk is high-impact and the change is feasible |
| Transfer | Shift the financial consequence to a third party — insurance, contracts, warranties | When the risk is financial and can be contractually allocated |
| Mitigate | Reduce the probability or impact of the risk | When you cannot eliminate or transfer the risk — most common strategy |
| Accept | Acknowledge the risk and take no proactive action — active (with contingency) or passive (without) | When the cost of response exceeds the cost of the risk materialising |
In the Barcelona API example: our primary strategy was Mitigation — weekly checkpoints and stub APIs reduced both the probability of delay and its impact on our development team. The escalation path was our Active Acceptance contingency — we accepted that the risk might still materialise but had a planned response ready.
Risk Opportunities — The Other Side of Risk
Many candidates study only negative risks (threats) and are caught off guard when exam questions address positive risks (opportunities). PMI’s risk management framework explicitly covers both.
For opportunities, the four response strategies are:
- Exploit: Eliminate uncertainty by ensuring the opportunity definitely occurs
- Share: Allocate ownership of the opportunity to a third party better positioned to capture it
- Enhance: Increase the probability or impact of a positive risk
- Accept: Take advantage of the opportunity if it occurs but do not actively pursue it
Memory tip for threats: Avoid, Transfer, Mitigate, Accept — in order of how aggressively you are dealing with the risk. Avoid is the most aggressive (eliminate it completely). Accept is the least aggressive (live with it). For opportunities, the mirror strategies are: Exploit, Share, Enhance, Accept.
How These Documents Are Tested on the PMP Exam
Pattern 1: Document Identification
A question describes a risk being tracked with probability, impact, owner, and response strategy. Which document is this? Answer: Risk Register. If the question describes a summary of top risks being presented to the project sponsor, the answer is Risk Report.
Pattern 2: When to Create Each
The Risk Register is created during risk identification — early in planning. The Risk Report is created during risk monitoring and control — throughout execution. If a question asks what the project manager creates first, the answer is the Risk Register.
Pattern 3: Risk Response Selection
Given a scenario, which response strategy is most appropriate? These questions require you to understand the difference between Avoid (eliminate the risk), Transfer (shift the financial consequence), Mitigate (reduce probability or impact), and Accept (do nothing proactive). The scenario context tells you which applies.
Pattern 4: Risk Owner Responsibility
The PMP exam frequently asks about risk ownership. In PMI’s framework, each risk has a named owner who is responsible for implementing the response strategy. The project manager does not personally own every risk — they ensure risks are identified, owned, and actively managed.
The most common mistake in real risk management — and one that the PMP exam explicitly tests against — is treating the risk register as a one-time document created during planning and never updated. Risk management is a continuous process. Risks are identified, assessed, responded to, and monitored throughout the entire project lifecycle.
About the Author:
Rahul Dhakate is a PMP-certified project manager and product management leader based in Nagpur, India, with 20 years of experience managing software projects across BFSI, eCommerce, and enterprise software. He prepared and maintained risk registers across multiple projects including a distributed eCommerce delivery with teams in India and Barcelona, where API delivery risk required active mitigation to protect the project timeline. He writes at LearnXYZ.in to help working professionals understand both the theory and the real-world practice of project management.
Good Reads
