Risk vs Issue Log: Differences, Fields and Examples

A risk log holds things that might happen and could change your project. An issue log holds things that have already happened and need action now. The two logs use different fields, different rhythms and different questions, and mixing them is how teams end up with a long list nobody trusts.

This guide shows where the line sits, what each log should contain, how an item moves from one to the other, and what it looks like in design and architecture work.

TL;DR

• A risk is uncertain and sits in the future. An issue is certain and sits in the present. The test is whether the event has already occurred.
• Risk entries need likelihood, impact and a response plan. Issue entries need an owner, urgency and a target date.
• When a risk happens, or its probability nears 100%, log it as an issue straight away and tell the team and sponsor.
• Keep the source of every entry: who raised it, when, and in which conversation. That is what makes a log useful months later.
• Review risks on a schedule and issues continuously.

Table of Contents

• The difference in one sentence each
• Why keep two logs instead of one
• What a risk log should contain
• What an issue log should contain
• What to do when a risk becomes an issue
• Examples from design and architecture work
• How to run both logs week to week
• The part most logs miss: where each entry came from
• Perspective: logs are only as good as the conversation behind them
• Keeping risks, issues and their sources together
• FAQ
• Sources

The difference in one sentence each

A risk is a potential problem that may or may not happen. PMI’s guidance on risks and issues notes that a risk can affect a project positively or negatively, while an issue that has occurred requires immediate action to resolve it.

The cleanest way to separate them is probability. PMI puts risks at anywhere from 1% to 99% likelihood, and issues at 100%. If it is certain, it is an issue. If it is still uncertain, it is a risk. That framing also explains a point made in the same source: there are no facts about the future, so anything not yet happened can only be assessed, not confirmed.

Tense is a quick check

The fastest edit you can make to a messy log is to read each entry for tense. Risk descriptions use the future tense, such as “if this happens, then this will be affected”, while issue descriptions use the present tense, such as “we have this problem”.

Why keep two logs instead of one

Some teams use a single combined list and it works for a very small job. It stops working when the list grows, because the two kinds of item need different attention.

Risks need judgment. You are asking what could go wrong, how likely it is and whether a cheap action today avoids an expensive one later. Issues need execution. Somebody must own the problem, set a date and report back. When both live in one list sorted by date, urgent problems hide among speculative worries, and speculative worries get ignored because the list feels like firefighting.

A second reason is accountability. PMI notes that a project manager may escalate an issue if its owner is unable or unwilling to drive its resolution. That escalation path makes sense for something already hurting the project. It makes less sense for a risk that may never occur.

What a risk log should contain

The fields below follow the structure published in OpenProject’s project management guide. Both logs share a base, and risk logs add four fields of their own.

Shared fields (both logs):

• ID
• Category
• Title
• Description
• Status
• Who identified the item
• Date identified
• Traceability and comments

Added for risks:

• Likelihood
• Impact
• Risk level (usually likelihood combined with impact)
• Response strategy

For the response, the standard options are to avoid, reduce, transfer or accept the risk. Pick one and write down what you will actually do. “Monitor” is not a response unless you say what you are watching and what triggers action.

The point of a response plan is to have it ready before it is needed. A contingency tied to a specific risk is far easier to execute under pressure, and the article on how to link your risk register to contingency shows the same idea applied to bidding work.

A short worked example

A small studio is designing a two-story residential addition. One entry might read:

• ID: R-07
• Category: Client requirements
• Description: If the client adds a rooftop terrace after schematic design, the structural layout and budget will need revision.
• Likelihood: Medium. The client mentioned it twice in meetings.
• Impact: High. Roughly two weeks of rework and a possible fee conversation.
• Response: Reduce. Ask for a go or no-go on the terrace at the next design meeting and record the answer.
• Owner: Project lead
• Source: Client call notes, with the date they were raised

Notice the last line. The risk exists because of something somebody said. Without that source, the entry is a guess; with it, anyone can go back and check how serious the signal really was.

What an issue log should contain

Issue entries start with the same shared fields, then add what you need to get the problem solved: action details, urgency, impact, size and a target date, per the OpenProject guide.

The same studio, a few weeks later, might log:

• ID: I-03
• Category: Client requirements
• Description: The client has confirmed the rooftop terrace. The structural layout and budget need revision.
• Urgency: High. The structural engineer needs the change before the next package.
• Impact: Two weeks of rework.
• Action: Revise the plan and send the engineer an updated brief.
• Owner: Project lead
• Target date: Set by the owner and agreed in the next meeting
• Linked record: R-07

The linked record matters. The OpenProject guide includes traceability and comments so related actions and records can be connected. That means the risk R-07 does not vanish when it occurs. It is closed as “occurred” and points to I-03, so the team keeps a visible history of what they foresaw and what they did about it.

What to do when a risk becomes an issue

This is the question that causes the most confusion, and it comes in two forms. One is the clear case: the event happened. The other is the grey case: the event has not happened but is nearly certain.

The University of Essex’s project guidance says an issue may be a risk with near 100% probability or one that has already happened, and that issues should be logged immediately and communicated to the project team and sponsor. That gives you a workable rule.

1. Confirm the trigger. Did the event happen, or is it now close to certain?
2. Create the issue entry immediately, written in present tense.
3. Close the risk entry with the outcome and a link to the new issue.
4. Assign an owner and a date. An issue without both is only a complaint.
5. Tell the team and the sponsor, or in a studio, the principal and, where relevant, the client.
6. Escalate if the owner cannot or will not resolve it.
7. Review afterward. Was the risk scored well? Was the response ready? Adjust your scoring habits for the next project.

There is a related question teams ask: where does a newly found risk go if you find it during execution rather than planning? It goes in the risk log. The log is not a planning-phase document. It is a living list that you add to every week.

Examples from design and architecture work

General project management content leans on construction schedules and software releases. Design work has its own pattern, and the examples are worth making concrete.

Research on product design finds that design risks can affect stakeholder needs, creating the risk of wrong objectives, or program execution, creating the risk of missing objectives. The same study reports that the highest-severity risks are requirements-related, followed by supplier-related risks. For a studio, that translates into a simple habit: watch what clients ask for and what outside parties promise.

Nielsen Norman Group describes design risks including a design being unfamiliar, hard to use, unpopular, too costly, abused or harmful. Those are useful prompts for brainstorming risk entries on any design job.

Here is how common studio situations sort out:

The last two matter because supplier problems rank high in the research. A quick prompt in each design review, “which outside party could slow us down?”, produces useful risk entries.

How to run both logs week to week

Logs fail because nobody looks at them, not because the fields are wrong. A rhythm that fits a small team:

• Weekly, 15 minutes: Read the risk log top to bottom by risk level. Ask of each: has anything changed, did a trigger fire, is the response still right? Promote anything that became an issue.
• Daily or as raised: Open issues with the owner and target date visible. Anything past its date gets a comment or an escalation.
• At each milestone: Close stale entries, record outcomes and check whether the risk scoring matched what happened.

Keep scoring simple. A three-level scale for likelihood and for impact is enough for a studio. The scale must be used consistently, which matters more than its precision.

Keep owners to one person per entry. A team named as owner is nobody’s job.

The part most logs miss: where each entry came from

Most risk and issue logs capture what, who and when. Few capture why the item is on the list. In design work that is the costly gap, because risks and issues usually come out of conversations: a client remark in a call, a reviewer’s comment in a critique, an offhand line in a meeting.

Six weeks later, a risk entry that reads “client may request changes to the facade” looks vague. A source-backed one tells you who said it, in which meeting, and what was decided next. That is what lets a new team member, or you after a busy month, judge whether the risk is real. It also helps you see the pattern when an issue lands: you can trace it back to the first time someone mentioned it.

This connects to related records your team probably keeps already. A decision log records what was decided and why, a constraints log holds the limits you are working inside, and action item tracking makes sure each issue’s fix has an owner. Client remarks that may become risks are easier to catch with client comment tracking, and a structured design review checklist is a dependable place to ask the risk questions out loud.

Perspective: logs are only as good as the conversation behind them

We build The Intent Ledger for design teams, and what we see repeatedly is that the log format is rarely the problem. Teams know the difference between a risk and an issue. What they lose is the reasoning. A risk gets written down as a single line, the meeting it came from fades, and when the problem arrives nobody can say whether it was foreseen, who agreed to the response, or what the client actually said.

Our view is that a risk or an issue is a piece of project memory, not just a row in a table. It should carry its origin with it. When a design decision changes because of a risk, the record should show the conversation, the rationale and the person who took the call. That is the idea behind preserving the why, not just the what, and it is why we focus on source-backed records rather than generic notes.

If you take one habit from this article, make it this: never log a risk or issue without noting where it came from.

, Rajas

Keeping risks, issues and their sources together

If your risks and issues come out of calls, critiques and client comments, The Intent Ledger turns those conversations into ILM Records: structured, source-backed entries for decisions, design intent, risks, actions, commitments and open questions, each traceable to the conversation it came from. You can start with a one-off pack, Working Set at $12 or Project Record at $29, or choose a monthly plan such as Working Memory at $29 per month. See all options on the pricing page, or read more at The Intent Ledger.

FAQ

What is the difference between a risk and an issue?

A risk is something that may happen and could affect the project. An issue is something that has already happened and needs action. Think of probability: risks sit between 1% and 99%, issues at 100%.

Should I keep a risk log and an issue log separately?

For anything beyond a very small job, yes. Risks need scoring and scheduled review, while issues need owners, dates and quick escalation. Separate logs keep urgent problems from being buried under possibilities, and a link field lets you trace a risk to the issue it became.

What should a risk log include?

At minimum, an ID, category, title, description, status, who raised it, the date, likelihood, impact, risk level and a response strategy, plus comments or links to related records. Add the source conversation so the reasoning can be checked later. This field list follows OpenProject’s published guide.

What happens when a risk becomes an issue?

Log it as an issue immediately, close the risk with its outcome, and tell the project team and sponsor. The same rule applies when a risk has not happened but its probability is close to 100%, as set out in University of Essex guidance.

Can a risk be positive?

Yes. PMI notes a risk can affect a project positively or negatively. A client considering a larger scope is an example. Log it as an opportunity, with a plan to be ready if it occurs.

Sources

• Risks vs. issues (PMI)
• You’ve got way too many issues! (PMI)
• Tried and true methods in managing project risks and issues (PMI)
• Appendices (OpenProject)
• Risk and issue management (University of Essex)
• Developing a Taxonomy for Risks in Product Design and Development (Design Society)
• Design Risks: How to Assess, Mitigate, and Manage Them (Nielsen Norman Group)
• Link your risk register to contingency (ProTenders)

Recommended

• Dependencies Log: Fields, Example and Review Rhythm
• Constraints Log for Small Studios: Assign Owners, Review Weekly
• Record of Decision: 8 Fields Design Teams Must Capture
• Commitment Tracking: 7 Fields That Let Design Teams Verify Promises