The line between the risk register and the issue log is a single word: "uncertain." The moment that uncertainty resolves, the entry has to move.
Project teams routinely mix these two logs, and the mixing has real consequences — a risk carries a probability and needs a contingency plan approved in advance, while an issue is already happening and needs a decision now. A risk is an uncertain future event that, if it occurs, would affect at least one project objective (schedule, cost, scope, or quality) — it might happen. An issue is a problem that has already occurred, or a certainty that has already materialized, and requires action today. The test PMP and PRINCE2 both apply is simple: has the uncertain event already happened? If yes, it's an issue (or has become one); if it's still a "might," it stays a risk.
The reason PMP and PRINCE2 both insist on separate registers isn't bureaucracy — it's that risk management only adds value if the response is decided beforethe pressure of an active problem forces a rushed decision. A risk register entry for "supplier may miss delivery" lets the team qualify a backup vendor calmly, weeks in advance, while there's no schedule pressure yet. If that same situation is only ever tracked as a live issue once the supplier actually misses the date, the team is now improvising a vendor search under active schedule pressure — the worst possible time to be doing that research for the first time. Converting a materialized risk into an issue (rather than starting a fresh, unprepared issue) is what preserves the value of having done the risk planning at all.
No — probability, even at 95%, is not the same as certainty. A risk logged at 95% likelihood is still, by definition, tracked with a response strategy chosen under uncertainty (you might still avoid or mitigate it before it happens), while an issue has zero uncertainty left to manage — the event already occurred or is already a known fact, and the only open question is how to resolve it. Some teams also mistakenly log a known unresolved problem discovered during planning— say, a design conflict already found in a drawing review — as a "risk," when it should go straight to the issue log, because there is no uncertainty about whether it exists; it is already a fact requiring resolution, just one discovered before execution began rather than during it.
Distinguishes the project risk register (uncertain future events with a probability and a prepared response strategy) from the issue log (problems that have already occurred and require an active resolution decision), and explains why a materialized risk should convert into an issue rather than being tracked twice.
Both live in a project manager's tracking toolkit, both get reviewed in status meetings, and both can describe the same underlying situation at different points in time — which is exactly why they get merged into one messy log on less disciplined projects. The distinguishing question is always temporal: is the event still uncertain (a risk) or has it already occurred, or is it already a known fact (an issue)?
A risk, per PMI's PMBOK Guide, is "an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives." Risks are logged with an owner, a probability, an impact estimate, and a chosen response strategy — avoid, mitigate, transfer, accept (for threats) or exploit, enhance, share, accept (for opportunities) — before the event happens.
An issue is a problem, gap, inconsistency, or conflict that has already materialized and requires resolution — PRINCE2 formally distinguishes issues into Requests for Change, Off-Specifications, and Problems/Concerns, each escalated to the Project Board if the Project Manager's tolerance is exceeded. An issue is tracked to closure with an owner, a resolution action, and a due date, not a probability.
Engineering projects generate both constantly: a risk register might flag "the geotechnical report may reveal unsuitable soil conditions" months before ground is broken, with a response plan (a pre-qualified pile-foundation alternative) chosen in advance. If the soil report then does come back showing unsuitable conditions, that specific risk closes and the situation reopens immediately as an issue — "unsuitable soil confirmed, foundation redesign required" — now tracked with a resolution owner and a hard deadline, not a probability. Losing that risk-to-issue conversion discipline is a common root cause of "we knew this could happen but somehow weren't ready when it did" project failures.
No — best practice is to mark it closed with a note showing it materialized and linking to the corresponding issue log entry, preserving the audit trail and letting future risk assessments learn from how accurate the original probability/impact estimate turned out to be.
Yes — resolving one issue sometimes introduces a new uncertain future consequence. For example, activating a backup vendor to resolve a missed-delivery issue might introduce a new risk: "the backup vendor's components may not pass incoming QA inspection," which gets logged fresh on the risk register.
Both are typically maintained by the Project Manager, but PRINCE2 requires certain issue types (Requests for Change, Off-Specifications that breach agreed tolerance) to be escalated to the Project Board for a formal decision — the risk register's response strategies, by contrast, are usually pre-approved within the Project Manager's existing tolerances.
No. An assumption is a statement taken as true for planning purposes without proof (e.g., "we assume the client will approve drawings within 5 business days"). If that assumption later proves false, it typically converts directly into a risk or an issue depending on whether the falseness is still uncertain or has already been confirmed — but the assumption itself, while unverified, is neither.
Try our Engineering Management, Business & Professional Skills Studio
More calculators, simulators, and guides for this discipline.
Data Analysis Studio
✨ Premium ContentA structured, paid professional training program for this discipline.