Risk register versus issue log: what goes in each, and the moment one becomes the other

A risk might happen. An issue already has. Everything else follows from that: a risk register carries a likelihood against every line, an issue log cannot, because the probability of something that has already occurred is not a useful number.

A risk has not happened yet, an issue has

HM Treasury’s Orange Book defines risk as the effect of uncertainty on objectives, and uncertainty is the operative word. Take it away and you no longer have a risk. You have a fact, and facts are managed differently: not watched, weighed and hedged, but fixed, absorbed or escalated.

That is why the two artefacts cannot be collapsed into one set of columns even when they live in one file. A risk needs a likelihood so that it can be ranked against other risks, and ranking is the entire reason a register exists, because nobody responds to forty risks equally. An issue needs a resolution date and an owner with the authority to act today. Ask an issue for a probability and somebody will dutifully write 100 percent, which sorts every issue to the top of a list that was designed to be sorted by something else.

A note on the naming, because it costs people time. Risk log and risk register mean the same thing. There is no distinction hiding in the two words, no convention where one is a summary and the other is the detail. Where a document is called a risks and issues log, it is one artefact doing both jobs, which is a filing decision and a reasonable one.

What actually goes in each

Field	Risk register	Issue log
Tense	Might happen	Has happened
Likelihood	Required, and the basis of ranking	Not applicable
Impact	Estimated, if it occurs	Observed, and often still moving
Owner	Watches and runs the response	Fixes it, with authority to act
Date	Review date	Resolution date
Closed when	The window passes or it occurs	The effect stops

Two rows in that table do more work than the rest.

Impact behaves differently in each. On a register it is an estimate of something that has not occurred, so it stays stable until the assessment is revisited. On an issue log it is a measurement of something in progress, and it moves. An issue logged on Monday at two days of delay may be at nine days by Friday, and a log that is not re-read weekly will report the Monday number for the rest of the quarter.

The closing conditions differ, and this is where registers rot. A risk closes for either of two reasons: the window for it passed, or it happened. Only the first is a clean close. Teams routinely close a risk when it occurs and open an unrelated-looking issue, which severs the link between the two and quietly deletes the fact that somebody saw it coming.

The moment a risk becomes an issue

The government’s Teal Book puts it in a single sentence: if a risk happens then it becomes an issue and needs to be managed as such. Simple to state, and the transition is where most registers lose their value.

Three things should happen at that line, and the third is the one that gets skipped.

The issue is raised, with an owner who can act and a date. The risk is closed with a reason of occurred, not deleted and not quietly marked withdrawn. And the two entries are linked, so that anyone reading the issue can see it was on the register for six weeks with a planned response that either was not run or did not work.

That third step is what turns a register from a compliance artefact into something that earns its keep. Without it, every quarter looks like a series of unforeseeable events. With it, you can answer a much better question at review: of the issues we handled this quarter, how many had been sitting on the register, and what did we do about them while there was still time.

The lines that are genuinely hard to place

The tense test settles most entries in a second. Four shapes resist it, and they are the ones that actually consume argument in a review.

The partly occurred risk. One instance has happened and more may. A supplier missed one delivery of twelve. That is an issue for the missed delivery, with an owner and a fix, and it remains a risk for the eleven outstanding, usually with a higher likelihood than before. Two lines, not one, and the second should have its score revised the same day. Collapsing it into a single entry loses whichever half you did not pick.

The chronic condition. The team is short two people, and has been for months. Nothing has occurred, so it is not an issue; nothing might happen, so it is not a risk. It is a state of the world, and it belongs in neither artefact. Put it wherever your governance keeps constraints and record the specific consequences it might cause as risks with their own lines. Conditions on a risk register never close, and a line that never closes trains people to skim past it.

The dependency that has slipped. A dependency is a separate RAID type for a reason, and the slip creates an issue only when it actually costs you something. A dependency arriving two weeks late into six weeks of float is a fact worth recording and not yet a problem worth managing. This is where a register that also tracks float earns its money, because the same slip against zero float is an issue the day it is known.

The event with no impact yet. The regulator has announced a consultation that may change your requirements. Something has definitely happened, which argues for the issue log, but nothing has landed on the work, which argues for the register. Log it as a risk with the trigger already fired and the impact still uncertain, and review it weekly rather than monthly. The tense test asks whether the event occurred; the more useful question here is whether the uncertainty has resolved, and it has not.

The through line is that the artefacts are sorted by uncertainty, not by drama. When a line is hard to place, ask what is still unknown about it. If something material is, it is a risk.

One log or two

The queries people type suggest most organisations run a combined risks and issues log, and there is nothing wrong with that. One file is easier to maintain, easier to bring to a meeting, and it keeps the escalation path visible: the issue appears three rows below the risk it came from.

What breaks is not the shared file, it is the shared columns. A merged sheet tends to grow one set of headings that has to serve both, and the compromise is always the same: likelihood becomes optional, then meaningless, then a column of 100 percents. Once that happens the register can no longer rank anything, which was its only job.

If you keep one document, keep the type on every line and keep the fields distinct even where a column is empty for half the rows. An empty likelihood cell on an issue is correct and informative. A likelihood of 100 percent on the same line is a small lie that makes the whole register unsortable.

What a log cannot do for you

Neither artefact makes a decision. Both are lists, and a list has never once mitigated anything.

The failure mode is well known and still common: the register is maintained diligently, reviewed at every meeting, colour coded and complete, and nothing on it changes what the team does. Every line has an owner, a score and a response written in the future tense that stays in the future tense for the life of the work. The register is not wrong. It is simply not connected to anything, and its completeness makes that hard to see.

Two questions expose it quickly. For any line on the register, what did we do differently this month because of it? And for any inherent score sitting next to a residual one, is the gap between them the result of work that actually happened, or of work that was planned? If the honest answers are nothing and planned, the register is documentation rather than management, and adding an issue log alongside it will not change that.

The register earns its place at the moment somebody moves a line into the issue log and can point at what was tried while it was still a risk. Everything else is filing.