Identify Risks in PMBOK 8 — Complete Guide

Article updated in March 2026 for the PMBOK® Guide — Eighth Edition.

Identify Risks in PMBOK 8 — Complete Guide

Formerly known as: Identify Risks (PMBOK 6)

The project had been running for eleven weeks when the integration with the payment processor failed. The error was not technical — it was contractual. The payment processor had quietly updated their API authentication protocol four months before the project started, and the project team had based their integration design on the old documentation. A risk identification session at project initiation would have surfaced this assumption in under ten minutes. The cost of not identifying it: six weeks of rework, a delayed go-live, and a $23,000 emergency consulting engagement to reverse-engineer the new authentication flow.

Every project risk that materializes as a crisis was once a risk that could have been identified. In PMBOK 8, Identify Risks is Process 2 of the Risk Domain. It is the process of identifying project threats and opportunities — both negative and positive risks — through an iterative approach that evolves as the project progresses and new information becomes available. The key distinction in PMBOK 8’s framing: an important part of identifying risks is separating real risks from concerns, and recognizing that initial risk identification is always incomplete. The process must be repeated throughout the project lifecycle, not performed once at planning and forgotten.

This complete guide covers everything a project manager or PMP candidate needs to understand, apply, and tailor the Identify Risks process in PMBOK 8:

• What it is — definition, distinction between risks, concerns, and issues
• Why use it — the compounding value of early and continuous risk identification
• Full ITTO — every input, tool, technique, and output explained
• Step-by-step application guide — from risk workshop to risk register
• When to apply it — initial identification and ongoing iterations
• Two real-world examples — Project Phoenix and Project ProjectAdm
• Templates and tools — with free downloads
• Five common errors — and how to avoid each one
• Tailoring — predictive, agile, and hybrid approaches
• Process interactions — what feeds in and what depends on identify risks
• Quick-application checklist — 10 items you can use today

1. What Is the Identify Risks Process

Identify Risks is the process of identifying project threats and opportunities. According to PMBOK 8, risk identification includes recognizing both negative and positive risks. The process focuses on distinguishing genuine risks from non-risks such as concerns and issues. It is important to recognize that not all risks can be identified at the outset due to the inherent uncertainties and unknowns present at the beginning of a project. Therefore, risk identification should be an iterative process, allowing for continuous identification and assessment of risks as more information becomes available and the project evolves.

PMBOK 8 introduces a critical conceptual framework for understanding risk types. Risks can be classified into four categories:

• Known-Unknown: The classic risk — there is knowledge to identify the probability and impact. These are what risk identification is designed to surface.
• Unknown-Known: Knowledge exists in the community but not with the entity working on the project (hidden facts). Risk identification using external expertise and checklists helps uncover these.
• Unknown-Unknown: Knowledge does not exist within the sphere of influence (emergent risks, black swan events). Cannot be identified in advance; addressed through project resilience and contingency reserves.
• Known-Known: Managed as part of scope. Not a risk.

The output of Identify Risks is primarily the Risk Register — the central register of all identified project risks — and the Risk Report, which provides a summary view of the overall risk profile of the project. Both outputs are living documents that must be updated throughout the project lifecycle.

2. Why Use the Identify Risks Process

Risk identification is the entry point to all subsequent risk management activity. No risk that is not identified can be analyzed, planned for, or monitored. The value of comprehensive, early, and continuous risk identification is multiplicative:

• Prevention over reaction: Every risk identified in planning and successfully mitigated eliminates the cost of the crisis it would have caused. Crisis management costs are typically 3–10 times greater than the cost of the preventive action that would have avoided them.
• Opportunity capture: PMBOK 8 explicitly includes positive risks (opportunities) in the identification process. An identified opportunity that is actively exploited can accelerate the schedule, reduce costs, or increase the project’s delivered value. Opportunities not identified are opportunities lost by default.
• Stakeholder confidence: A project team that demonstrates systematic risk identification and management inspires confidence in sponsors and clients. It communicates organizational maturity and professional competence.
• Budget and schedule realism: Risk identification directly informs contingency reserve calculations. Projects without identified risks have no rational basis for contingency — which means either no contingency (and certain budget overruns) or arbitrary contingency (waste or underfunding).
• Team engagement: Inclusive risk identification sessions where team members contribute their domain knowledge create shared ownership of risk management. Team members who identified a risk feel accountable for monitoring and managing it.

3. Inputs, Tools & Techniques, and Outputs (ITTO)

The following table presents the complete ITTO of the Identify Risks process as defined in PMBOK 8:

Inputs explained

Risk management plan: The specific input that defines how risk identification will be conducted: the methodology to be used, the frequency of identification activities, the roles and responsibilities of risk identification participants, the risk categories and prompt lists to be used, and the risk register format and content requirements. Risk identification without a risk management plan produces inconsistent, uncoordinated results.

Assumption log: Every assumption documented in the assumption log is a potential risk. If an assumption proves false, it typically creates a risk event. Reviewing the assumption log during risk identification converts hidden assumptions into explicit risks, dramatically improving the completeness of the initial risk register.

Scope, schedule, and cost baselines: The three baselines are the primary risk targets. Scope complexity creates scope risk. Schedule constraints create schedule risk. Cost constraints create budget risk. A systematic review of the baselines through a risk lens — asking “what could prevent this scope item from being delivered on time and within budget?” — is one of the most productive risk identification techniques available.

Stakeholder register: Stakeholders who are identified as having high impact or high interest in the project are also potential sources of risk — through scope escalation, changing requirements, conflicting priorities, or political opposition. Reviewing the stakeholder register during risk identification surfaces stakeholder-related risks that would otherwise be missed in purely technical identification sessions.

Tools & Techniques explained

Brainstorming: A facilitated group session designed to generate a large volume of risk ideas in a short time. Effective brainstorming for risk identification uses structured prompting (by WBS element, project phase, risk category, or stakeholder perspective), divergent thinking rules (no evaluation or criticism during idea generation), and a skilled facilitator who prevents premature narrowing. A 90-minute risk brainstorming session with a cross-functional team is typically the most productive single risk identification activity available for most projects.

Checklists: Pre-built lists of common risks for a specific project type, industry, or technology context. Checklists prevent the team from reinventing the risk identification wheel and ensure that well-known risks from organizational experience are not missed. Effective checklists are developed from historical project lessons learned, updated after each project, and tailored to the specific project context rather than applied generically.

Interviews: One-on-one structured conversations with subject matter experts, key stakeholders, and experienced project managers to surface risks that would not emerge in a group setting. Individual interviews are particularly valuable for surfacing political risks, sensitive stakeholder risks, and technical risks that experts may be reluctant to raise in a group.

Root cause analysis: Working backward from potential adverse outcomes to identify the underlying causes that could trigger them. Root cause analysis in risk identification asks: “If this outcome were to occur, what would have caused it?” This reversal of the typical root cause direction is a powerful technique for identifying risks from outcomes rather than from causes.

Assumption and constraint analysis: A systematic review of every documented assumption and constraint to identify associated risks. For each assumption, the analysis asks: “What is the probability that this assumption is false, and what would be the impact?” For each constraint, the analysis asks: “What risks are created by this constraint?”

Prompt lists: Structured lists of risk categories and risk drivers that prompt the team to think broadly about risk sources. Common prompt structures include PESTLE (Political, Economic, Social, Technological, Legal, Environmental), TECOP (Technical, External, Commercial, Organizational, Project Management), and VUCA (Volatility, Uncertainty, Complexity, Ambiguity). Prompt lists prevent the team from fixating on technical risks while ignoring organizational, regulatory, and market risks.

Artificial intelligence: PMBOK 8 specifically includes AI as a risk identification technique. AI-powered tools can analyze project data, historical project performance, and external databases to identify risk patterns that human analysis would miss. Natural language processing tools can analyze project documents for hidden assumptions and risk indicators. This is a growing area that will continue to expand in project management practice.

Outputs explained

Risk Register: The central output of Identify Risks, the risk register records every identified risk with: a unique ID; risk description (in “cause, event, consequence” format); risk category; risk owner; probability assessment (initial qualitative); impact assessment (initial qualitative); risk response approach (preliminary); and current status. The risk register is a living document — it is updated by every subsequent risk management process throughout the project lifecycle.

Risk Report: A summary document that provides an overview of the overall risk profile: the total number of risks identified, the distribution by category and severity, the top risks, and the overall risk exposure assessment. The risk report is intended for sponsor and stakeholder communication, providing a strategic view of the project’s risk landscape.

↓ Free risk register and risk report templates available at Risk Register — Software Development and Risk Report Template.

4. Step-by-Step Application Guide

Step 1 — Review the risk management plan and prepare identification tools

Before any identification activity, review the risk management plan to confirm the methodology, categories, prompt lists, and register format. Prepare all identification tools: brainstorming facilitation materials, checklist templates, interview guides, and assumption log summaries. Invite participants who represent all major project domains.

Step 2 — Review all inputs systematically

Before the brainstorming session, review the key inputs individually: assumption log, scope baseline, schedule baseline, cost estimates, stakeholder register, and lessons learned from similar projects. Create a preliminary risk list from this desk review. This list provides the brainstorming session with a structured starting point rather than a blank canvas.

Step 3 — Facilitate a cross-functional risk identification workshop

Run a structured 90-minute risk identification workshop with the project team and key stakeholders. Use the preliminary risk list as a starting point and apply brainstorming, prompt lists, and assumption analysis to expand and refine it. Record every risk idea without evaluation during the session. Apply the root cause analysis technique to the highest-priority deliverables to surface additional risks.

Step 4 — Conduct individual expert interviews

Following the workshop, interview 2–4 subject matter experts or key stakeholders individually to surface risks that did not emerge in the group setting. Technical leads, compliance specialists, and key stakeholders who may not be comfortable raising risks publicly in a group are the priority targets for individual interviews.

Step 5 — Document all identified risks in the risk register

Compile all identified risks from the workshop and interviews into the risk register. Write each risk in the “cause, event, consequence” format: “Due to [cause], [event] may occur, which would result in [consequence].” This format ensures that the risk is precisely defined, preventing the common error of documenting vague categories (e.g., “technical risk”) rather than specific, actionable risks. Assign initial owners and schedule the next identification cycle.

5. When to Apply This Process

Risk identification is iterative, not one-time. Key application moments include:

• Project initiation: Initial identification to populate the risk register before planning begins
• Planning phase: Comprehensive identification workshop as planning documents are finalized
• Each phase gate: Re-identification to capture risks that have emerged during the completed phase
• Sprint planning (agile): Brief sprint-level risk identification to surface risks for the upcoming iteration
• Major scope or schedule changes: Any approved change triggers a risk identification update
• External environment changes: Significant changes in market, regulatory, or organizational context trigger risk re-identification

6. Real-World Examples

Example 1: Project Phoenix — Website Launch

Alex Morgan facilitated a two-hour risk identification workshop in day 5 of planning for Project Phoenix, attended by all seven team members, the TechCorp sponsor Sarah Chen, and the Shopify integration specialist. Using a prompt list based on TECOP categories, the team identified 23 risks in the session. The individual interviews that followed surfaced three additional risks that would not have emerged in the group: a regulatory risk around PCI DSS compliance for the payment processing integration (identified by the specialist), a stakeholder risk around the client’s internal approval process for design sign-offs (identified through an individual conversation with Sarah Chen), and a technical risk around the legacy CRM system’s API compatibility with the new website (identified by the back-end developer in a private conversation).

The risk that proved most valuable to identify was the PCI DSS compliance requirement. Without it, the team would have begun the payment integration without the required security controls, potentially triggering a compliance failure that would have delayed the go-live by 6–8 weeks and exposed TechCorp to regulatory penalties. Because the risk was identified, the team engaged a PCI DSS consultant early, completed the compliance requirements on schedule, and went live on time.

Example 2: Project ProjectAdm — SaaS PM Platform

For Project ProjectAdm’s 18-month timeline, Eduardo implemented a structured risk identification cadence: a comprehensive initial workshop at project start (identified 47 risks), phase-gate identification sessions at months 3, 6, 9, 12, and 15 (each adding 5–12 new risks as the project evolved), and sprint-level identification in each two-week sprint planning session (typically surfacing 1–3 tactical risks). By project month 12, the risk register contained 89 entries, of which 31 had been closed (risks that did not materialize or had been successfully mitigated), 18 were actively monitored, and 40 had been transferred to the issue log when they materialized as actual problems.

The iterative approach captured risks that could not have been identified at project initiation: a market risk in month 7 when a major competitor launched a feature that overlapped with ProjectAdm’s core value proposition (identified through a PESTLE review at the phase 3 gate), and a technology risk in month 10 when the cloud provider announced deprecation of a service the platform depended on (identified through continuous environmental monitoring).

7. Templates and Downloads

• Risk Register — Software Development — Comprehensive risk register template with all PMBOK 8 required fields.
• Risk Report Template — Risk report template for sponsor and stakeholder communication.
• Risk Management Plan Template — Complete risk management plan template governing all risk processes.

8. Five Common Errors

Error 1 — Performing risk identification only once

Risk identification performed once at project initiation and never revisited will miss the majority of risks that actually materialize, because most project risks emerge from evolving project conditions rather than from the initial project design. PMBOK 8 explicitly positions identify risks as an iterative process. Projects that identify risks once are not managing risk — they are managing the risk register of week one.

Error 2 — Identifying only threats and ignoring opportunities

PMBOK 8 defines risk as including both threats (negative) and opportunities (positive). Risk identification sessions focused exclusively on what could go wrong systematically miss the opportunities that proactive risk management could exploit. A project team that consistently identifies and exploits opportunities delivers more value than the plan predicted; a team that ignores them leaves value on the table by default.

Error 3 — Documenting risk categories instead of specific risks

A risk register entry that reads “technical risk” or “resource risk” is not a risk — it is a category. Specific, actionable risks are written in the “cause, event, consequence” format: “Due to the team’s lack of Kubernetes experience, the containerization milestone may be delayed by 2–3 weeks, which would delay all dependent integration testing.” Vague categories cannot be analyzed, prioritized, responded to, or monitored.

Error 4 — Excluding team members from risk identification

Risk identification workshops attended only by the project manager and sponsors miss the domain knowledge of the people actually doing the work. Developers identify technical risks that sponsors cannot see. QA engineers identify quality risks that developers overlook. Inclusive identification sessions produce more complete and more accurate risk registers, and create shared ownership of risk management across the team.

Error 5 — Confusing risks, issues, and concerns

PMBOK 8 explicitly distinguishes: a risk is an uncertain future event that has not yet occurred; an issue is a problem that has already occurred or is currently occurring; a concern is a worry or discomfort that is not yet sufficiently defined to be a risk. Mixing these categories produces a risk register that conflates management disciplines, creating confusion about which problems require immediate action and which require monitoring and preparation.

9. Tailoring This Process

Predictive approach: Comprehensive upfront risk identification with a formal workshop, followed by periodic re-identification at defined intervals and phase gates. Risk register is maintained as a formal project document.

Adaptive approach: Sprint-level risk identification is integrated into sprint planning. A risk board or risk backlog is maintained alongside the product backlog. Overall project risks are reviewed in retrospectives. The emphasis shifts to rapid identification and response rather than comprehensive upfront documentation.

Hybrid approach: Formal initial risk identification for the predictive framework, with agile sprint-level identification for the adaptive components. Risk interfaces between the two approaches are explicitly managed.

Large/complex projects: Dedicated risk workshops with breakout sessions by domain. External risk specialists for specific risk categories. AI-assisted risk pattern analysis. Formal risk taxonomy and categorization framework.

10. Process Interactions

Identify Risks is the gateway process for all subsequent risk management activity:

Inputs from: The Plan Risk Management process provides the framework within which identification operates. The Initiate Project or Phase process provides the project charter and assumption log. The Integrate and Align Project Plans process provides the complete plan as a risk identification input.

Outputs to: The Perform Qualitative Risk Analysis process receives the risk register for prioritization. The Perform Quantitative Risk Analysis process receives high-priority risks for numerical assessment. The Plan Risk Responses process develops responses based on identified and analyzed risks. The Monitor Risks process tracks identified risks throughout execution. See the PMBOK 8 Guide Index for the complete process map.

11. Quick-Application Checklist

• ☐ Risk management plan reviewed before starting identification
• ☐ Assumption log, stakeholder register, and project baselines reviewed as inputs
• ☐ Prompt lists prepared (TECOP, PESTLE, or equivalent) for the workshop
• ☐ Cross-functional team assembled for the identification workshop
• ☐ Brainstorming session facilitated with divergent-then-convergent structure
• ☐ Individual interviews conducted with 2–4 key subject matter experts
• ☐ All risks documented in “cause, event, consequence” format
• ☐ Risks distinguished from concerns and issues in the register
• ☐ Risk register shared with team and risk owners assigned
• ☐ Next identification cycle date scheduled and entered in the project calendar

Call to Action:

References

Project Management Institute (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition. Newtown Square, Pennsylvania, USA: Project Management Institute, 2025.

PMBOK Guide 8: The New Era of Value-Based Project Management. Available at: https://projectmanagement.com.br/pmbok-guide-8/

Disclaimer

This article is an independent educational interpretation of the PMBOK® Guide – Eighth Edition, developed for informational purposes by ProjectManagement.com.br. It does not reproduce or redistribute proprietary PMI content. All trademarks, including PMI, PMBOK, and Project Management Institute, are the property of the Project Management Institute, Inc. For access to the complete and official content, purchase the guide from Amazon or download it for free at https://www.pmi.org/standards/pmbok if you are a PMI member.