Risk Register vs Risk Report vs Issue Log: What Goes Where?

Most project managers can define these three records if you ask them cold. The difficulty is rarely definitional. It shows up on a Thursday afternoon when something has gone wrong, three people want an update, and the record that should tell you where the project stands contains forty rows of uncertainty, several of which stopped being uncertain a fortnight ago.

That is the question behind the search. Not what the words mean, but where a particular piece of information belongs, who will read it once it is there, and what goes wrong if it is filed in the wrong place.

The short answer is that the risk register holds individual uncertainties you are actively managing, each with an owner and an agreed response. The risk report gives a higher-level view of overall exposure, concentration and direction of travel, written for people who will never open the register. The issue log holds what has already happened and now needs resolving. The longer answer is about purpose, because these three records drift together the moment nobody is clear on what each one is actually for.

Three records, three different readers

The risk register is a working instrument. It is where the project manager and the risk owners do the actual work: what might happen, how likely it is, what effect it would have, who owns it, what response has been agreed, whether that response has been carried out, and what exposure remains afterwards. Its reader is the person doing the managing. It is normally far too granular to be useful to anyone else, and that granularity is the point rather than a flaw.

The risk report answers a different question. Not "what are we doing about risk 27" but "how exposed is this project overall, and is that position improving or deteriorating". Concentration is central to it. Eight separate register entries that all depend on the same supplier are one exposure wearing eight hats, and no amount of reading down the register will make that visible. Direction of travel usually matters more than the current snapshot. The readers are sponsors, steering groups, portfolio functions and assurance colleagues.

Sending those readers the register instead of a report is one of the most common substitutions in practice. It rarely fails because the information is wrong. It fails because the analysis has been passed to the person least equipped to do it, in the ten minutes before a governance meeting.

The issue log covers what is happening now. An issue is not uncertain, so probability and impact ratings do not belong to it. The management question changes shape entirely: who is resolving this, by when, what it is costing while it remains open, and whether anyone outside the project needs to know. Different fields, different review cadence, different conversation.

Section 4 of the PMBOK® Guide - Eighth Edition, which sets out project inputs and outputs, treats the register, the report and the issue log as separate artefacts rather than as three formats of one document. The useful reading of that separation is not that three files are mandatory. It is that each one exists because a different question is being asked, and combining them tends to answer none of them well.

The moment a risk actually happens

When an identified risk occurs, the register entry does not simply get deleted. It gets closed with an outcome, and a corresponding entry opens in the issue log with a resolution owner and a date. That sequence preserves something valuable: the project can later show that the situation was foreseen, what response was agreed, and whether that response was carried out before the event.

Two errors are common here and they pull in opposite directions.

The first is leaving an occurred risk in the register. It keeps a probability figure that has become meaningless, it sits alongside genuine uncertainties and dilutes them, and, most seriously, nobody has been made accountable for resolving it. Risk owners own responses. Issue owners own resolutions. Those are not the same job.

The second is logging as an issue something that has not yet happened. This looks decisive and quietly converts planning into firefighting, because an issue log full of hypotheticals stops being a list of things needing action today.

It is also worth resisting the tidy assumption that every issue began life as a risk. Many issues were never identified in advance. A project where each issue has a matching prior register entry is usually a project where somebody has been backfilling, and the register has become a record of hindsight rather than foresight.

One rollout, three records doing different work

Consider a warehouse management system being rolled out to six regional distribution sites over nine months.

During planning, the team identifies that the supplier's implementation consultants are shared across two other client programmes, so specialist availability could slip at each site cutover. That goes in the register. The owner is the supplier account manager. The agreed response is that named consultants are written into the schedule for every cutover window and confirmed six weeks ahead.

Six weeks before the second site goes live, the confirmation does not arrive. Nothing has failed yet, so this is not an issue. What has changed is that the agreed response has not been executed, which means residual exposure has risen. The register entry is updated to say so, and the project manager chases.

Two weeks out, the supplier confirms that one of the two named consultants is unavailable. That has now happened. It moves to the issue log with the project manager as owner, and the resolution options are concrete: defer the cutover by three weeks, proceed with reduced supplier cover and heavier internal support, or escalate under the contract.

The steering group meets that month and needs neither of those entries. What it needs is the report, and the report says something the register cannot: that dependency on a single supplier now runs through four of the six remaining cutovers, that the agreed mitigation has already failed once, and that the exposure is concentrated tightly enough for one contractual conversation to reduce it materially. That is a governance decision. It only becomes visible when someone has looked across the register rather than down it.

When the form changes but the purpose does not

None of this depends on holding three spreadsheets. In adaptive delivery, the working record of uncertainty may live as items in the backlog or on an impediment board, current problems may be raised and cleared inside the team's normal cadence, and the higher-level view may be two paragraphs prepared for a review. In hybrid programmes, a formal register often coexists with team-level impediment handling, which works as long as everyone knows which of the two a given item sits in.

What travels across all three approaches is the underlying question. Is this uncertain or has it happened? Am I managing it or reporting on it? Who reads this, and what decision does it support? A team that can answer those three questions consistently is doing risk management properly whatever the artefacts are called. A team that cannot will produce impeccable documents that nobody uses. If you want to work through this kind of judgement in a structured, instructor-led setting, the PMP® Exam Preparation course develops the same habit across the wider syllabus.

For a PMP candidate, the important distinction is that situational questions rarely ask you to name a record. They describe a situation and ask what you would do next, and the correct next action very often depends on whether the thing described has already occurred. The 2026 PMP Examination Content Outline, effective July 2026, places this work in Domain III, Business Environment, which accounts for 26 per cent of the examination. Task 4 covers removing impediments and managing issues, and includes recognising when a risk becomes an issue. Task 5 covers planning and managing risk, and includes maintaining a risk register and communicating the status of a risk impact on the project. Reading a scenario carefully enough to spot which of those two you are in is worth more than memorising the field list of either record.

On a live project, the test is simpler still. If a colleague joined on Monday and read all three records, could they tell you what the project is worried about, what it is currently dealing with, and how exposed it is overall? If the answer is no, the problem is almost never the template. It is that somebody stopped asking what the record was for.

Andre Malowney

Interested in going further?

Deciding where information belongs, and what a governance audience actually needs to see, is judgement rather than administration, and it is exactly the kind of decision the PMP examination tests through situational scenarios. Structured preparation gives you a consistent way to read those situations and to apply the same reasoning to your own project records.

The PMBOK® Guide - Eighth Edition sets out these artefacts and the wider set of project inputs and outputs, and is a useful reference if you want to see how they sit alongside each other.

Ad · Amazon affiliate link.

References

A169: Assumption Log vs Risk Register
A171: Change Log vs Issue Log
A153: Risk vs Issue: The Difference That Changes What You Do Next
A170: Decision Log: The Forgotten Project Control
A154: When Does a Risk Become an Issue?

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