Risk Register vs Issue Log: What Goes Where and Why It Matters

Open the project tracker at most PMOs and you'll find a single tab labeled "Risks & Issues." It looks efficient. It is actually where a live problem burning through this week's schedule sits in the same rows, sorted by the same columns, and reviewed on the same cadence as a thing that might never happen at all.

That single tab is why risk reviews turn into fire drills and why urgent problems wait for a biweekly meeting that was scheduled to talk about hypotheticals. Risk register vs issue log isn't a naming preference. It's the difference between managing what could happen and managing what already has, and collapsing the two into one artifact quietly breaks both.

TL;DR. A risk is something that might happen: probabilistic, future-facing, and managed by mitigation before it occurs. An issue is something that has happened: certain, present-facing, and managed by resolution after the fact. Keeping them in separate artifacts, a risk register and an issue log, changes who owns each item, how often it gets reviewed, and how it gets escalated. The moment a risk's trigger condition fires, it graduates out of the register and into the log; it does not live in both.

What Actually Separates a Risk From an Issue

A risk is a statement about the future with a probability attached. "The vendor's API might not be ready by the integration date" is a risk: it has not happened yet, it may never happen, and the probability sits somewhere between zero and certain. An issue is a statement about the present with no probability at all. "The vendor's API is not ready and the integration date is in nine days" is an issue: it has happened, the probability is 100 percent, and the only open question is how the team responds.

That distinction sounds obvious stated plainly. It gets lost constantly in practice because both items describe the same underlying threat at different points in time, and teams default to tracking the threat rather than tracking its state. The vendor API problem starts life as a risk during planning, gets logged, gets a mitigation plan, and then, if the vendor actually misses the date, needs to become something else entirely: an item with a deadline, an owner accountable for resolution this week, and an escalation path if that resolution doesn't land. Most trackers never make that handoff explicit, so the item just sits where it started, mislabeled for the rest of the project.

The practical test is simple: if you can assign it a probability less than 100 percent, it is a risk. If the probability is 100 percent because it already happened, it is an issue. Wikipedia's overview of risk registers describes the register as a repository for identified risks with probability, impact, and mitigation fields, exactly the forward-looking structure that an issue log doesn't need and shouldn't carry.

Why One Merged Tracker Quietly Breaks Both

A "Risks & Issues" tab feels efficient because it's one less document to maintain. What it actually does is force both categories into a review rhythm that fits neither.

Risks reviewed at issue urgency get worked reactively even though nothing has happened yet. A PM under pressure to show progress starts assigning mitigation tasks to a risk that's still sitting at 20 percent probability, burning team capacity on a problem that may never materialize, while a genuinely urgent risk with 70 percent probability and three weeks to trigger gets the same one-line treatment in the same weekly scan.

Issues reviewed at risk cadence get worse. An issue that surfaces on a Tuesday sits in the merged tracker until the next scheduled risk review, sometimes a week or two away, because the tracker's rhythm was built around risks that don't need daily attention. By the time it surfaces in that review, the schedule impact has compounded and the resolution options have narrowed. The team didn't miss the issue. The tracker's cadence was built for the wrong kind of item, and the issue inherited that cadence by living in the same document.

The reporting confusion compounds at the steering committee level. A sponsor scanning a merged list can't tell at a glance which rows demand a decision this week and which rows are contingency planning for something that hasn't happened. Every row looks equally urgent or equally hypothetical, and sponsors default to skimming past all of them, which defeats the point of tracking either category in the first place.

What Fields Belong in a Risk Register

A risk register earns its keep when it captures enough structure to actually drive mitigation, not just a running list of worries. The fields that matter:

• Description: what could happen, stated specifically enough that someone unfamiliar with the project understands the threat
• Probability: a percentage or a coarse scale (low/medium/high), reassessed at each review
• Impact: what happens to schedule, cost, or scope if the risk fires, in specific terms
• Risk score: probability multiplied by impact, used to rank and triage
• Mitigation plan: what the team is doing now to reduce probability or impact before the risk fires
• Contingency plan: what the team will do if the risk fires anyway, prepared in advance rather than improvised under pressure
• Trigger condition: the specific, observable event that would convert this risk into an issue
• Owner: the person accountable for watching the trigger and executing mitigation
• Review date: when this entry gets reassessed next

The trigger condition is the field most registers skip, and it's the one that makes the risk register vs issue log split actually work in practice. Without a defined trigger, nobody knows the moment a risk has fired; it just quietly becomes "kind of an issue now" without a clean handoff, and it often keeps living in the risk register long after it should have moved.

What Fields Belong in an Issue Log

An issue log is not a risk register with the probability column deleted. It needs its own structure, oriented around resolution rather than mitigation:

• Description: what has actually happened, stated as fact
• Date raised: when the issue was identified, which anchors how long it's been open
• Severity: how much schedule, cost, or scope damage this is causing right now
• Resolution plan: the specific action that closes this issue, not a mitigation strategy for something that hasn't happened
• Deadline: when a decision or resolution is needed to avoid further schedule impact
• Owner: the person accountable for driving resolution, who may be different from the original risk owner
• Status: open, in progress, or resolved, updated continuously rather than at a scheduled review
• Escalation level: how far up the chain this has gone if it isn't resolving on the original timeline

Severity in an issue log measures current damage. Impact in a risk register measures potential future damage. They look similar on a form and mean something different, which is another reason a shared "impact" column across a merged tracker produces numbers nobody can compare honestly.

Risk Register vs Issue Log at a Glance

Dimension	Risk Register	Issue Log
Time orientation	Future: something that might happen	Present: something that has happened
Certainty	Probabilistic, less than 100 percent	Certain, 100 percent
Core fields	Probability, impact, mitigation plan, trigger condition	Date raised, severity, resolution plan, deadline
Management style	Proactive: reduce probability or impact before it fires	Reactive: resolve the problem that already exists
Review cadence	Scheduled, weekly or biweekly	Continuous, escalated by urgency
Entry trigger	Identified during planning or a risk review	A risk fires, or an unplanned problem surfaces directly
What a sponsor needs from it	A sense of exposure and what's being done about it	A clear decision or resource ask, with a deadline

When Does a Risk Become an Issue?

The transition should be a defined event, not a vague drift. The moment the trigger condition on a risk actually occurs, that entry closes out of the risk register and opens as a new entry in the issue log. The diagram below shows the handoff: a risk lives in the register with probability and mitigation fields until its trigger fires, at which point it becomes an issue with severity and resolution fields instead.

The clean version of this handoff is a five-minute process: close the risk entry with a note pointing to the new issue ID, open the issue with its own severity and deadline, and assign an owner, who may or may not be the original risk owner. Teams that skip this and just edit the existing row in place lose the history of what the risk looked like before it fired, which is exactly the data a post-project retrospective needs to judge whether the original mitigation plan was any good.

Teams migrating off Microsoft Project Online run into a version of this problem directly: PWA's Issues and Risks lists already keep the two as separate SharePoint lists, and it's tempting during a migration to flatten them into one spreadsheet for simplicity. That flattening throws away years of a distinction the old tool got right.

Who Owns Each Artifact, and How Does Escalation Differ?

The PM typically owns both artifacts at the project level, meaning the PM is accountable for making sure both get maintained and reviewed. Individual entries need their own named owners, and the two roles aren't interchangeable.

A risk owner watches a specific trigger condition and is accountable for executing the mitigation plan before that trigger fires. This is a monitoring role: the risk owner's job succeeds if the trigger never occurs, or if it occurs and the mitigation already reduced the impact enough that the resulting issue is manageable.

An issue owner drives a specific problem to resolution against a deadline. This is a delivery role: the issue owner's job succeeds when the issue closes, not when it's merely being watched. Assigning an issue to the same passive ownership model as a risk, "keep an eye on it," is how issues drift for weeks without anyone actually being on the hook for closing them.

Escalation differs the same way. A risk escalates when its probability or impact score crosses a threshold defined in the project's risk management approach, typically moving it from the PM's radar to the steering committee's. An issue escalates on a timeline: if it isn't resolved by its deadline, it moves up a level automatically, because an unresolved issue is compounding cost every day it sits open, unlike a risk that hasn't fired yet.

The Reporting Cadence Each One Needs

Risk registers and issue logs don't just need separate fields and separate owners; they need separate rhythms, and forcing them into the same meeting is where most merged trackers fail operationally.

1. Review the risk register on a fixed schedule. Weekly for active-risk projects, biweekly for stable ones. Risks change slowly enough that a scheduled look catches drift without demanding daily attention.
2. Review the issue log continuously, not on a schedule. New issues get logged and triaged the day they're identified, and open issues get a status check at every standup, not just at the risk review.
3. Report risks as exposure, not incidents. A steering committee update on risk should read as "here's what we're watching and what we're doing about it," a forward-looking statement.
4. Report issues as decisions or asks. A steering committee update on issues should read as "here's what's blocked and what we need from you to unblock it by Friday," a present-tense request.
5. Keep the two sections visually distinct in every status report, even if they appear in the same document, so a reader can tell in one glance which rows are hypothetical and which are active. The status reporting discipline that makes a weekly update worth reading applies directly here: separate what might happen from what is happening.

How to Split a Merged Tracker Without a Big-Bang Migration

Most PMOs inheriting a merged "Risks & Issues" tab don't need to rebuild their tooling to fix this. The split is mostly a triage exercise:

1. Tag every existing row as either a risk or an issue using the 100-percent-probability test: if it has already happened, it's an issue regardless of what column it's currently sitting in.
2. Create two separate views or tabs, even if they live in the same underlying spreadsheet or tool, so the two lists can have different columns and different sort orders.
3. Add the missing fields to each. Risks that never had a trigger condition need one added now. Issues that never had a deadline need one assigned immediately.
4. Assign explicit owners to every entry, not just a general "PM owns this," matching the risk-owner and issue-owner distinction above.
5. Set the two review cadences separately on the team calendar, so the issue log gets checked far more often than the risk register.
6. Write the trigger-to-issue handoff into the project's risk management approach so the next risk that fires gets moved cleanly instead of drifting in place.

None of this requires new software. It requires treating "risk" and "issue" as two different questions with two different answers, instead of one column that tries to answer both at once. A project that keeps these separate reports more honestly, escalates faster when it matters, and gives a retrospective something real to evaluate: not a merged list of things that went wrong, but a clean record of what the team saw coming and what caught it by surprise.

Microsoft Project Online™ is a trademark of Microsoft Corporation. Onplana is not affiliated with Microsoft.