Risk vs Issue: The Difference That Changes What You Do Next
Open most risk registers and you will find at least one row that has stopped being a risk. The probability is marked at ninety per cent, the response was never started, the review date has been rolled forward twice, and the event it describes happened some time in the spring. Nobody has moved it. Moving it would mean saying out loud that something has gone wrong, and a register is a quieter place to keep that news than an issue log.
The definitions themselves are not difficult. A risk is an uncertain event or condition that would affect the project if it occurred. An issue is a condition that exists now and needs managing. The distinction earns its keep because of what follows from it. While something is still uncertain, a set of preventive responses remains available and the work can be planned at a sensible pace. Once it has happened, those responses close, a different set opens, and the clock starts.
The test is whether anything is still uncertain
The most common sorting error is by severity. Small and containable goes in the register, large and alarming gets called an issue, and the team ends up with a filing system based on how worried people feel. Severity has nothing to do with it. A minor supplier invoicing error that occurred last week is an issue. A credible threat of losing the only person who understands the payments interface, which would cost the project three months, is a risk until the day the resignation lands.
Two questions settle almost every case. Has the event actually occurred, or is it still a possibility? And is there uncertainty left that could still be influenced? A supplier warning that they may miss a date is a risk. A supplier who has missed the date has handed you an issue. A regulator that might extend its review period is a risk. A regulator that has written to say the review will take a further eight weeks has created a condition you now have to manage around.
The grey area is partial occurrence, and it is where most teams get stuck. Performance drifts rather than fails. A dependency slips by two days when the risk described a two-week slip. Here the answer is usually to split the entry instead of arguing about the label. Name the part that has happened, which needs an owner and an action this week, and name the part that is still open, which needs a response and a review date. Section 2.7.1 of the PMBOK® Guide Eighth Edition treats risk, issue and uncertainty as separate key concepts within the Risk Performance Domain, and the separation carries through into how each one is handled. Uncertainty is the broader condition, covering ambiguity and variability as well as identifiable events, and a good deal of what lands on a project belongs there before it is precise enough to be either a risk or an issue.
It is worth keeping assumptions and constraints out of this as well. An assumption is something you have accepted as true without proof, and it usually generates a risk rather than being one. A constraint is a boundary you are working within. A dependency is a relationship between pieces of work. None of them belong in a risk register in their own right, though each of them can produce entries that do.
What changes when the label changes
Risk responses work on likelihood and consequence before the event. You can avoid, transfer, reduce or knowingly accept, and where the uncertainty is favourable you can act to make it more likely. All of that depends on time you no longer have once the event has occurred. Issue management is a different activity: contain the effect, recover what can be recovered, decide what to do about the consequences that cannot be undone, and then look at what the event has changed about the rest of the plan.
Money moves differently too. Contingency reserve is held against identified risks and is normally drawn on when one of them materialises, which is exactly what it was calculated for. That is usually within the project manager's authority. An issue whose cost runs beyond the reserve, or one nobody identified in advance, becomes a governance conversation about management reserve, funding or a change to the baseline. The label therefore determines who is signing, and that is often the real reason people hesitate before moving an entry.
Cadence and record change in the same moment. Risks are reviewed on a cycle, with owners, responses and trigger conditions, and a register that is reviewed monthly is usually reviewed often enough. An issue needs an owner, an action and a date now, recorded where current issues live and not buried in a list of possibilities. Reporting changes with it. A sponsor reading a risk report is being told what might happen and what you are doing about it. A sponsor reading an issue entry is being told what has happened and what you need from them.
One missed date, two entries
A regional housing association is replacing its finance system. The register carries an entry that the supplier may not deliver the integration test environment by 14 May, assessed as medium probability and high impact, with a weekly supplier check-in and a contractual milestone as the response. On 16 May the environment is not there, and the supplier is offering a new date of the 29th.
The instinctive move is to raise the probability to high and note the slippage in the comments. That entry is now describing the past. The missed date is an issue: someone owns the recovery of the environment, there is an action with a date, and the commercial position needs a decision about whether the milestone is invoked. Recording the outcome and closing the risk entry matters as well, because the register is also the record of which of your identified risks actually came to pass, which is worth a great deal to whoever plans the next migration.
Two new risks come out of the same event. Compressed test cycles may push user acceptance testing into the year-end finance freeze, which would be a serious problem and can still be influenced. Defects found late in a shortened cycle may exceed the remaining contingency. Neither has happened. Both deserve a response, an owner and a trigger, and both are best raised while there is still room to act on them. One event has produced one issue and two risks, and the project is now managing all three in the places they belong.
Where the distinction quietly breaks down
Registers become graveyards gradually. Entries accumulate, some of them describe events that have already occurred, nobody closes anything, and the review turns into a reading exercise. The cost shows up later, when a sponsor stops treating the risk report as useful information because they have learned that most of it is historic. A register with twelve live entries that are genuinely uncertain is worth more than one with sixty that nobody can act on.
The opposite failure is just as unhelpful. Some teams call everything an issue, escalate each one, and train their steering group to skim. An issue log that fills up with observations, irritations and things nobody intends to act on stops being a management tool. If an entry has no owner and no action, it is not an issue: it is a note.
There is also the version that is nobody's accident. Keeping something in the register when it has plainly occurred delays the conversation that would follow, and it is usually done by people under pressure rather than people behaving badly. The practical protection is agreeing escalation thresholds before anything goes wrong, so that moving an entry becomes a normal administrative act rather than a personal decision to give somebody bad news.
For a PMP candidate, the useful habit is to read the first sentence of a scenario for tense before reaching for a response. Whether the event has happened determines whether you are being asked about analysis and response planning or about containment and escalation, and the plausible-looking wrong answer in these questions is frequently the right action applied at the wrong stage. The current PMP Examination Content Outline names recognising when a risk becomes an issue among the enablers for removing impediments and managing issues in the Business Environment domain, so the judgement is explicitly part of what the exam assesses rather than a preparation convention. Practising the reclassification on a register you did not write is a good exercise, and it sits close to the reasoning that structured PMP® Exam Preparation is designed to develop.
On a live project the discipline is simpler than it sounds. When something changes, ask what has actually happened and what is still open, then put each part where a decision can be made about it. A register holds what might still be prevented. An issue log holds what now has to be handled. Sorting the two honestly, week by week, is most of what separates a project that sees trouble coming from one that reports it afterwards.
Interested in going further?
Classifying uncertainty correctly under pressure is a judgement that improves with structured practice against realistic situations, particularly where the funding route and the escalation path change with the answer. Omega's PMP® Exam Preparation works through that reasoning in predictive, adaptive and hybrid contexts.
The Risk Performance Domain in the PMBOK® Guide Eighth Edition sets out these key concepts in full, including where risk and issue sit within the wider handling of project uncertainty.
Ad · Amazon affiliate link.
References
A154: When Does a Risk Become an Issue?
A158: Threats and Opportunities: Risk Is Not Always Negative
A155: Risk Register vs Risk Report vs Issue Log: What Goes Where?
A159: Risk Appetite, Tolerance and Threshold: Stop Mixing Them Up
A152: The PMBOK 8 Risk Performance Domain: What It Really Covers
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
