When Does a Risk Become an Issue?

Most project managers have sat through the same short disagreement. Someone says the supplier delay is now an issue. Someone else says it is still a risk, because the supplier has not formally missed a date yet. The register says one thing and the conversation says another, and the meeting usually moves on without resolving it, because the point feels administrative rather than real.

It is not administrative. The moment something is reclassified from a risk to an issue, the work changes character. You stop trying to influence whether an event occurs and start managing what it has already done. Different people become involved, money is drawn from a different place, and a different level of governance applies. Getting the timing wrong in either direction carries a cost, which is why the question deserves a better answer than "when it feels serious enough".

The test is certainty, not seriousness

A risk is an uncertain event or condition that may affect project objectives. An issue is something that has occurred, or a condition that is now present, and that needs managing. The Risk Performance Domain described in Section 2.7 of the PMBOK® Guide Eighth Edition rests the distinction on that first word. Once the event has happened, probability stops being a meaningful quantity. You cannot sensibly assign a forty per cent likelihood to something already sitting in front of you.

That gives a clean test. A risk becomes an issue when the uncertainty is gone.

Two habits get in the way of applying it. The first is converting on severity. A risk moves to red on the report, the exposure looks alarming, and someone reclassifies it as an issue on that basis. Red means high exposure, not resolved uncertainty. A high-probability, high-impact risk that has not yet happened is still a risk, and treating it as an issue removes exactly the window in which you can still influence whether it occurs at all.

The second is converting on visibility. Escalation gets mistaken for materialisation. A risk can be raised to the sponsor, discussed at a steering group and given board attention while remaining entirely hypothetical. Attention is not occurrence.

The reverse failure is quieter and more common. Nobody converts, because conversion is an admission. The risk stays in the register with a probability that everyone privately knows is now one hundred per cent, the mitigation is still shown as in progress, and the consequence accumulates for another reporting cycle before anybody says so out loud.

Where the judgement actually gets difficult

The rule is simple. The situations are not, and this is where a competent project manager earns their keep.

Partial materialisation is the most frequent. The risk was framed at project level and has occurred on one workstream: a single supplier has missed a milestone, and the integrated delivery date has not moved. The useful response is usually to convert what has happened, at the level at which it has happened, while keeping the wider uncertainty in the register with revised exposure. Converting the whole thing overstates the position. Converting nothing understates it.

Conditions with a gradual onset are harder. Some risks were never described as events at all. A risk that a key supplier's financial position may deteriorate does not resolve on a particular Tuesday. It arrives through late payments, staff departures and slower responses. Waiting for a formal announcement means waiting for the point at which your options have narrowed. Ask instead whether the condition is now true enough that you would act differently if you accepted it.

Materialisation can also leave the risk alive. If a data feed has failed once and could fail again, you have both an issue to resolve and a live risk of recurrence. Closing the register entry because the thing has happened loses the recurrence.

The near miss belongs in a category of its own. Something almost happened and did not. That is evidence your probability assessment was wrong, and it calls for reassessing the risk rather than reclassifying it.

The way to make these easier is to decide in advance. When a risk is written, write the condition that will signal it has occurred: something observable, attributable to someone who will notice it, and expressed as a date, a threshold or a state. "If the vendor confirmation is not received by the fifteenth" is a trigger. "If the situation deteriorates significantly" is a future argument.

Consider a consultancy delivering a finance system replacement. The team logs a risk that the client's only specialist in the legacy pricing rules may not be available during the build window. The agreed response is three structured knowledge-capture sessions with her before build starts. Two weeks before the first session, she is seconded full time to a regulatory response for eight weeks.

Has the risk occurred? The event as written was unavailability during the build window. She is now unavailable, and the date is known. The condition is true, so it converts, and the consultant arriving to run the first session finds the client's delivery lead already on the phone arranging cover. That is the change in character made visible. The session was designed to reduce the probability of a knowledge gap. It is now a conversation about consequence.

Notice what conversion does not do. It does not tell you the response plan still works, and here it plainly does not, because the plan depended on the person who has gone. It also generates new risk: undocumented pricing logic now creates a credible risk of defects surfacing late in system testing, which belongs in the register as a fresh entry. Conversion is rarely a tidy status change from one column to another.

What changes the moment it converts

Management attention moves from likelihood to consequence. The questions stop being about prevention and start being about containment, recovery, notification and the point at which the impact becomes irreversible.

The planned response has to be tested. Contingency plans are written under conditions that no longer apply, and a proportion of them are unusable the moment they are needed. Finding that out on the day is a normal experience, and the first act after conversion is often to check whether the response you wrote is still executable.

Money moves. The 2026 PMP Examination Content Outline includes quantifying risk and contingency financial allocations, and managing financial reserves, within the finance task. Provision set aside against a specific risk is now either being drawn on or is visibly insufficient, and that belongs in a governance conversation.

Ownership is worth a second look. The person best placed to monitor an uncertainty may not be the right person to resolve a live problem, and carrying the name across from one artefact to the other by default is a common way for issues to sit unactioned.

The delivery approach changes the mechanics. On a predictive project, conversion is usually formal: the register entry is closed with an outcome, an issue is raised with an owner and a target resolution date, and contingency is drawn against an agreed threshold. On an adaptive project, many teams do not maintain a separate issue log at all. The materialised risk becomes an impediment, surfaces at the team's coordination point, and is reprioritised into the current iteration. On a hybrid project, the genuine question is which layer needs to know. A team can often absorb the consequence within its own cycle while the programme is still tracking the same uncertainty at a level where the escalation threshold has now been crossed.

Why the exam files this under issues rather than risk

The 2026 PMP Examination Content Outline places the recognition of a risk becoming an issue in Domain III, Business Environment, within the task covering impediment removal and issue management, rather than in the separate task on planning and managing risk. Domain III accounts for twenty-six per cent of the exam. The classification is a useful signal in itself: the outline treats recognising the conversion as part of dealing with what has landed, alongside evaluating impact and agreeing an approach with stakeholders.

For a PMP candidate, the practical habit is to read a situation for tense before reading it for severity. A scenario describing something that may affect delivery is asking about uncertainty and calls for risk thinking. A scenario describing something that has occurred is asking about impact, response and who now needs to be involved, however uncertain the eventual outcome remains. The skill is noticing which of the two a situation is actually in. Working that classification against realistic project situations is what PMP® Exam Preparation develops across risk, governance and stakeholder decisions.

On a real project, the discipline is smaller than it sounds. It is one question at every risk review, asked before anything else: which of these has stopped being uncertain? Most reviews spend their time re-scoring probabilities that have not changed, while the two or three entries that have quietly resolved sit untouched because nobody was asked to look for them. A register that never converts anything is not a stable project. It is usually a register that has stopped being read.

Andre Malowney

Interested in going further?

Recognising the moment a risk converts is one of those judgements that looks obvious in a definition and turns awkward in a live review, particularly when the materialisation is partial or gradual. Structured preparation helps because it puts that decision alongside the governance, finance and stakeholder consequences that follow it, rather than treating risk as a self-contained topic.

The PMBOK® Guide - Eighth Edition sets out the Risk Performance Domain in full if you want the wider framing behind the risk and issue distinction used here.

Ad · Amazon affiliate link.

References

A152: The PMBOK 8 Risk Performance Domain: What It Really Covers
A153: Risk vs Issue: The Difference That Changes What You Do Next
A157: Do Agile and Hybrid Projects Still Use Risk Registers?
A164: Risk Owners vs Action Owners
A155: Risk Register vs Risk Report vs Issue Log: What Goes Where?

PMP and PMBOK are registered marks of the Project Management Institute, Inc.