Issue Log vs Risk Register: What's the Difference?
A risk register records things that might happen, scored by probability and impact, with a response chosen in advance. An issue log records things that have already happened and are affecting the project now, with an owner and a resolution date. A risk that materialises becomes an issue. Both are usually kept, because they are reviewed on different cadences by different people.
Side by side
The distinction is certainty. Everything in a risk register is conditional; everything in an issue log has already landed. That single difference drives every other field on the two logs.
| Aspect | Issue log | Risk register |
|---|---|---|
| What it records | Something that has happened | Something that might happen |
| Certainty | Certain — it is here | Uncertain — expressed as a probability |
| Core fields | Description, current impact, owner, resolution, due date | Description, probability, impact, score, response, owner |
| Scoring | Severity or priority | Probability multiplied by impact |
| Typical responses | Resolve, escalate, or absorb the consequence | Mitigate, avoid, transfer, or accept |
| When an entry closes | When the problem is fixed or formally absorbed | When the risk has passed, or when it occurs |
| Movement between the two | An unresolved issue often creates new risks | A risk that occurs is retired and raised as an issue |
| Review cadence | Daily to weekly | Weekly to monthly, plus at gates |
| Primary audience | Delivery team, then escalation route | Project board and steering committee |
| Where it usually lives | The "I" of a RAID log | The "R" of a RAID log, or a standalone register |
When you need an issue log
An issue log is the working document of a delivery team. It exists so that nothing that is currently hurting the project is being held only in someone's head. The test for an entry is blunt: is this happening now, and is it costing us time, money, scope or quality? If yes, it belongs on the log with a named owner and a date by which it will be resolved or escalated.
The fields that make the difference are the ones people skip. Current impact in plain terms — two days of testing lost per week, not "medium". Date raised, because age is the most reliable signal that something is stuck. And an explicit escalation date: the point at which, if this is still open, it goes up a level automatically rather than because someone remembered.
Issue logs get reviewed frequently because their contents change fast. A weekly cycle is the minimum on an active project; during a cutover window it is hourly. That cadence is why the log needs to be short and sortable rather than beautiful. A structure that supports this sits in the RAID log template, where issues share a sheet with risks, assumptions and dependencies but keep their own status and ageing.
When you need a risk register
A risk register is a governance document. It exists so that a board can see what could go wrong, how likely it is, what it would cost, and what is being done about it in advance. That audience wants scoring, trend and ownership at a level above the delivery team.
The mechanics matter more here than on the issue log. A risk needs a cause, an event and a consequence written separately, otherwise the entry becomes untestable — "resourcing" is not a risk, "the integration developer is shared with two other programmes, so the interface build may start late, delaying system test by three weeks" is. It needs probability and impact scored on a scale everyone uses the same way, a pre-agreed response, and a residual score after that response.
Registers also need presenting, which is a different job from maintaining them. A heatmap, a movement view showing what has changed since last time, and an escalation list are what a committee actually reads. Our risk register template in PowerPoint is built for that half of the job; the working register itself normally stays in a spreadsheet.
When you need both
Almost always. They answer different questions on different clocks, and collapsing them into one list means either the board reads operational noise or the team's live problems get reviewed monthly.
The connection between them is what most projects handle badly. Three transitions need to be explicit. First, a risk that occurs should be closed on the register with the reason "materialised" and raised as an issue with a reference back — not quietly deleted. Second, an issue that has been open too long usually generates a new risk about its knock-on effect, and that risk belongs on the register. Third, an assumption that proves false becomes an issue immediately, which is one of the reasons assumptions sit alongside both in a RAID structure.
Keeping them in one workbook with a shared reference number makes those transitions traceable rather than aspirational. The programme governance pack keeps risks, issues, dependencies, actions and the weekly status report reading from the same register, so an issue raised on Tuesday appears in Friday's report without being retyped.
The overlap
In practice the two lists blur, and pretending otherwise causes arguments in review meetings. A risk scored at ninety per cent probability is, for all operational purposes, an issue that has not been admitted yet. An issue that is partly contained is really a residual risk with a live consequence. Teams waste real time debating which column something belongs in.
The useful rule is to stop arguing about the label and ask what the entry needs. If it needs someone to fix something this week, it needs the issue treatment: owner, action, date, escalation. If it needs a decision about whether to spend money now to avoid a larger cost later, it needs the risk treatment: probability, impact, response options, residual position. Some entries genuinely need both, and there is no harm in a cross-reference.
The other overlap is with the wider RAID structure. Assumptions and dependencies sit next to these two because they convert into them constantly. If you want the full picture of what belongs where, RAID log vs risk register covers the container question, and the RAID log guide covers the columns worth having in each section.
Questions
Can one log hold both risks and issues?
Yes, and a RAID log does exactly that. The entries still need separate status fields and separate review cadences, because a board reviews risks monthly while a team reviews issues weekly or daily.
What happens to a risk when it occurs?
It is closed on the register with the outcome recorded, and raised as an issue with a reference back to the original risk. Deleting it loses the evidence that the risk was known about in advance.
Should issues be scored like risks?
Issues are usually scored by severity or priority rather than probability and impact, since probability is no longer relevant. What matters is current impact and how quickly it needs resolving.
Who owns each log?
The project manager maintains both. Individual entries need individual owners — the person who can actually resolve the issue or execute the risk response, not the person who raised it.
How many open issues is too many?
There is no threshold worth quoting. The signal to watch is age: a growing number of issues open longer than their due date usually means the escalation route is not working.