Issue vs risk: what goes in the issue log and what goes in the risk register

Issue vs risk: the definitions

A risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on at least one project objective: scope, time, cost or quality. It has a probability below 100% and sits in the future. Negative risks are threats; positive risks are opportunities.

An issue is a current problem, question or condition that is already affecting the project, or will do so with certainty unless someone acts. Its probability is effectively 100%. Issues need an owner, a decision and a date, not a likelihood score.

The two registers answer different questions. The risk register asks what could happen and how prepared you are. The issue log asks what is going wrong right now and who is fixing it. Mixing them hides urgent problems among speculative ones and makes both lists harder to manage.

Side by side comparison

A useful side effect: when a risk occurs, it becomes an issue. You close the risk (status "occurred"), open an issue that links back to it, and run the contingency plan you already wrote.

Worked examples: sort these five entries

Here is a typical mixed list from a weekly meeting, sorted with the "what if or what now" test.

The last row shows a common trap. Vague statements of worry are not risks until you name a cause, an event and an effect.

Another grey area is the open question. "Which cable size does the client want?" is an issue if work is waiting for the answer, and nothing at all if the answer is not needed for months. Log it when it blocks or will soon block a task, and give it the date by which the answer is needed.

The columns each register needs

Risk register: ID, title written as cause, event and effect; category; threat or opportunity; owner; probability and impact scores (often on a 5×5 matrix); cost and schedule exposure; response strategy and actions; trigger; due date; status. Exposure in money is often expressed as expected monetary value (EMV = probability × impact): a 20% chance of a $50,000 overrun gives an EMV of $10,000.

Issue log: ID, title and description; date raised; raised by; owner; priority (for example high, medium, low); impact on scope, time or cost; action needed; target resolution date; status; linked risk or change request; resolution notes.

Keep the issue log short and blunt. If an issue needs a change to budget, dates or scope to resolve it, raise a change request and link it rather than approving the change inside the issue.

Running both logs: a weekly and monthly rhythm

The two registers work best with different meeting slots.

1. Weekly, 15 minutes on issues. Go through open issues by priority. For each one, confirm the owner, the next action and the date. Close anything resolved and verified. Escalate anything that has missed its date twice.
2. Weekly, 5 minutes on new risks. Ask the team one question: "what has changed that could hurt or help us?" Add new entries to the risk register with an owner; score them later if needed.
3. Monthly, 30 to 60 minutes on risks. Re-score the top risks, check that response actions are happening, look at triggers, and retire risks whose window has passed.
4. At every phase or gate. Run a fresh identification workshop, because each phase brings different risks.

When a risk occurs, follow the same short routine each time: set the risk status to occurred, open a linked issue with an owner and date, start the contingency plan, raise a change request if the baseline must move, and later record the actual cost and delay against the original estimate. That last step improves your next set of estimates more than anything else.

Common mistakes

• Logging issues as risks with 100% probability. It inflates the risk register and hides problems that need action this week.
• Never closing risks that occurred. Mark them occurred, link the new issue, and record what the response actually cost.
• Issues without owners or dates. An issue with no owner is a complaint, not a log entry.
• Using the issue log for change approval. Changes to the baseline go through change control.
• Reviewing both lists at the same pace. Issues need a short, frequent cycle; risks need a deliberate, regular review.

How to do this in Critova

Critova keeps the two lists separate on purpose. The risk register shows risks as a list, a board by status or a clickable 5×5 matrix, with owners, responses, due dates, cost and schedule exposure and EMV. Issues and change requests have their own registers, and a change request records its budget and date impact when it is approved or rejected. See the risk features, or read the project risk management guide for the full process.