“Decision Log vs Risk Log vs Issue Log”

What is the difference between a decision log, a risk log and an issue log?

decision log vs risk log vs issue log is a key topic in modern project management and teamwork. The difference is the tense of the item and the question it answers. A decision log answers “what did we choose, and on what basis?” A risk log answers “what could happen that would affect the objectives?” An issue log answers “what is happening right now that needs action?”

A test for a borderline item: remove all uncertainty and assume everything goes to plan. Decisions still exist; they are choices about the plan. Risks disappear; they are contingencies. Issues disappear only if the problem never happened — which means the entry should have been a risk first.

The risk register and issue log appear as named artifacts in the major bodies of knowledge; the decision log is less standardised, though architecture practice has used the same idea since Michael Nygard’s 2011 architecture decision record format. The pattern is older than software: board minutes are a decision log with worse indexing.

What belongs in a decision log?

Anything someone might reasonably question later: scope choices, design selections, supplier selections, schedule trade-offs, accepted deviations, policy exceptions. The test is not importance but reconstructability — if a new team member asks “why is it like this?”, the answer should be a log entry, not a memory of a meeting.

An entry needs enough context to be understood without the meeting: ID, date, the decision in one sentence, alternatives considered, rationale, owner, status, and consequences, including what the decision makes harder.

What does not belong: status updates, tasks, and opinions without a choice. “Discussed the database options” is not a decision; “chose PostgreSQL over MySQL for JSONB support and existing team skills” is. A meeting that produces no choice produces no decision entry, which is a legitimate outcome.

> Common mistake: Logging decisions without the alternatives that were rejected. Six months later, someone proposes the rejected option as a new idea, and the team re-runs the entire debate because the log only records the winner.

What belongs in a risk log?

Uncertain events that would affect scope, schedule, cost, quality, or outcomes. ISO 31000 defines risk as the effect of uncertainty on objectives, which is a useful boundary: if an item has no plausible effect on an objective, it is a worry, not a risk.

Each risk needs a cause, an event, and an effect, because that structure determines the response. “Supplier risk” is not manageable. “Because the radio modules are single-sourced (cause), a factory shutdown (event) would delay 40 sites by six weeks (effect)” is manageable: qualify a second source, or hold buffer stock.

Two fields do most of the work. Probability times impact gives a score that lets you sort; a trigger converts a passive register into an early-warning system. A risk with no trigger is a risk nobody is watching, because the owner has no instruction about when to act.

Worked example: the expected cost of a single risk

A risk has a 30% probability and an impact of three weeks of delay. If delay costs $12,000 per week in extended overhead, the expected cost is 0.30 × 3 × $12,000 = $10,800. A mitigation that costs $6,000 and halves the probability to 15% reduces expected cost to $5,400 — a net benefit of $5,400 against the mitigation spend, before counting the value of a more predictable launch.

That arithmetic does not make the estimate precise. It makes the conversation about mitigation rational, which is the point. Teams that never quantify risk end up arguing about whether a mitigation “feels worth it.”

What belongs in an issue log?

Problems that have already occurred and need resolution. An issue is a fact, not a forecast: the server is down, the permit was refused, the key developer resigned, the client changed a requirement after sign-off. The entry assigns ownership and tracks resolution; it is not a place to analyse what might have been.

Issue fields should be shorter than risk fields, because speed matters: ID, date raised, description, impact, priority, owner, target date, status, resolution. Add a root cause only when the same issue recurs, otherwise root-cause analysis becomes a reason to delay the fix.

The last field connects the three logs. If an issue links to a known risk, the review question is not “why did this happen?” but “why did the response not work?” If it links to no risk, the question is what was missed and whether it suggests a new risk category. Both beat a blame discussion.

How do items move between the three logs?

Items move when their status changes, and the movement should be recorded rather than copy-pasted. Four transitions matter: risk to issue, issue to decision, decision to risk, and issue to risk.

The most common failure is the risk-to-issue transition: teams leave the risk open while also opening an issue, so the register keeps counting a risk that already materialised. Close or mark the risk, and carry the impact into the issue.

Worked example: one event through all three logs

A payments platform has a release in ten weeks, and a single-sourced vendor supplies a security module.

The table is the whole argument for three logs. The risk explains why the team was watching. The decision explains why they stayed single-sourced. The issue explains what it cost and who fixed it. A single combined list would have recorded the delay three times and explained it zero times.

How do you keep three logs from becoming bureaucracy?

Use one ID scheme, review all three in the same weekly session, cap open high-priority items, and retire entries aggressively. Bureaucracy comes from logs nobody reads and entries nobody closes, not from the number of logs.

Rules that survive contact with a real project:

• One prefix and number series per log: D-, R-, I-, so cross-links are readable.
• A single weekly triage of 30 minutes: new and changed risks, new and ageing issues, pending decisions. Anything untouched for three weeks is closed or escalated.
• A definition of “high”: a threshold that decides who sees the item. Without it, everything is high.
• A WIP limit of about five open issues per owner. Beyond that, the log is a wish list.
• Decisions recorded at the moment of choice, not reconstructed on Friday from Tuesday’s meeting.

> Practical tip: Put the decision log in the same document as the meeting notes, but keep the risk and issue registers separate and structured. Decisions are narrative; risks and issues are data that needs filtering and ageing.

Which log should a small project start with?

Start with the issue log and a decision log, then add a risk log when an uncertainty appears that you cannot resolve this week. A five-person, six-week project rarely needs a formal register; it needs what is broken and what was chosen.

The sequence builds the habit. An issue log is immediately useful: it answers “who is fixing this?” A decision log pays off later but is cheap. A risk log earns its keep only when there is lead time for a response; on a two-week project, most risks become issues before a mitigation is approved.

Scale up when the project runs longer than three months, when more than one team depends on the same decisions, or when a plausible risk costs more than managing it. Then add probability, impact, triggers, and a review cadence.

What are the most common mistakes?

Five mistakes cause most of the damage: duplicating items, assigning owners who cannot act, recording decisions without alternatives, keeping risks open after they materialise, and treating logs as an audit artefact rather than a working tool.

The ownership mistake is the most expensive. A risk owner who cannot influence probability or impact is a name on a spreadsheet, not a control. A decision owner who did not make the decision is a scapegoat. An issue owner without authority to allocate time is a messenger.

Duplication is the easiest to fix and the hardest to notice. If the same problem appears as R-021, I-032, and an action in the minutes, three people update three statuses and the steering meeting hears three versions. Cross-reference, then close the redundant entries in the same session.

The audit-artefact mistake appears when logs are maintained for a gate review and abandoned afterwards. The test: does the weekly meeting use the log to make a decision? If not, it exists for someone else’s process and will die once that process is satisfied.

Should you keep one register or three logs?

One combined register works for small projects if each row declares its type, and the type changes the fields required. Three logs work better once cadences, owners, and audiences diverge.

Keep the decision log separate: its content is narrative and its review cycle follows meetings, not status. Risks and issues can share a register with a type column if the team is disciplined about forecast versus fact.

Where a shared workspace helps

The failure mode in all three logs is the same: the entry exists, but the person who needs it cannot find it. A workspace such as Doitify can hold risks with owners, scores, triggers, and responses; issues with priority and ageing; and meeting notes with the decisions that came out of them, linked to one project and visible in one activity trail. Reports then show ageing issues and high risks without rebuilding a spreadsheet weekly. Doitify is our product, so treat this as a description of fit, not a review; a small team with a disciplined review can run all three logs in one well-structured document.

What matters is the linkage, not the tool. A risk that becomes an issue should leave a trace, and a decision that creates a risk should sit one click from the consequence.

Conclusion

The decision log, risk log, and issue log are not three versions of one document. They answer three questions: what did we choose, what might happen, and what is happening now. Once that is clear, most arguments about which document is authoritative disappear.

Keep fields minimal, IDs consistent, transitions explicit. Close risks when they materialise, link issues to the decisions that resolve them, and record decisions at the moment of choice with the alternatives that lost. Review weekly; retire anything untouched for three weeks.

The test is not completeness but whether the next steering meeting decides faster because the record exists. If it does, the logs work; if not, they are decoration.

If this post on decision log vs risk log vs issue log was helpful, you might also enjoy Free Weekly Project Report Template (2026) and Project Management Software for Engineering Teams in 2026.