Meetings & Communication Guide

Published: 2026-10-30 · Reviewed: 2026-11-04

How to Keep a Decision Log: A Practical Guide

Every organisation makes hundreds of decisions a year, and forgets most of them. Six months later, someone asks “why did we choose this supplier?” or “who approved the price increase?”, and the answer is a shrug, a search through old emails, and a meeting to re-decide what was already decided. A decision log is the cure: a single, running record of what was decided, by whom, when, and why.

This guide shows how to use the Decision Log Template to build an organisational memory that actually works. It’s written for managers, project leads, and operations staff in small-to-mid businesses, the people who live with the consequences of forgotten decisions.

When to Use This

Use a decision log for any decision with consequences beyond the week: spending commitments, policy changes, supplier selections, hiring decisions, strategic pivots, project scope changes. The test is simple: if someone might reasonably ask “why did we do it this way?” in six months, log it.

Don’t log trivia. “We decided to order lunch from the Italian place” doesn’t need a record. “We decided to switch our payment processor, affecting all customer transactions from July” absolutely does. When in doubt, log it, an unnecessary entry costs one line; a forgotten decision costs a re-litigation.

How to Fill It Out

Section 1: Decision reference and date. Give each decision a simple reference number (D-2026-014) and the date it was made. The reference number is what lets people cite the decision later, “per D-2026-014” in an email is clearer than “as we agreed in that meeting in March.” Date it when the decision was made, not when it was logged; if there’s a gap, note it.

Section 2: The decision. State the decision in one clear sentence, written so that someone unfamiliar with the context understands what was chosen. “Approved: switch the company’s payment processor from PayFlow to TransactPro, effective 1 July.” Not “Payment processor, decided.” The decision statement should name the choice made, not just the topic discussed.

Section 3: Context and rationale. Why was this decided? Summarise the reasoning and the key facts that drove it: “TransactPro’s fees are 0.4% lower per transaction (saving an estimated 9,600 annually), their settlement time is one day faster, and the migration was quoted at three weeks. The main risk identified was integration effort, which the development team assessed as manageable.” This is the section future readers need most. Decisions without reasons get re-opened; decisions with reasons get respected.

Section 4: Alternatives considered. Briefly note what else was on the table and why it was rejected. “Also considered: staying with PayFlow (rejected, fees 18% higher after their March increase) and SettleFast (rejected, no multi-currency support).” Recording rejected alternatives stops the same options being re-proposed every quarter by people who weren’t in the room.

Section 5: Decision maker and stakeholders. Who made the decision, and who was consulted? “Decided by: the finance director, with input from the development lead and the operations manager. Approved by the CEO.” This matters for accountability and for authority, a decision made by someone without the authority to make it isn’t a decision, it’s a suggestion. If the decision required board or owner approval, note that and the date it was given.

Section 6: Impact and review date. What does the decision affect, and when should it be revisited? “Impact: all customer payments, finance reconciliation process, monthly reporting. Review: January 2027, or sooner if transaction fees change.” Most decisions aren’t forever, noting the review date turns the log from a archive into a management tool. When the review date arrives, the entry gets revisited: still valid, or time to decide again?

Common Mistakes

1. Logging decisions without the reasoning. “We chose supplier B” is a fact without a defence. When the decision is questioned, and the expensive ones always are, the reasoning is what justifies it. Two or three sentences on the why is the minimum that makes a log entry useful.

2. Letting the log go stale. A decision log that’s updated for a month and then abandoned is worse than none at all, because people assume it’s current. Assign one person to own the log, and make “any new decisions to log?” a standing item in the management meeting. Five minutes a week keeps it alive.

3. Recording decisions nobody had the authority to make. If the log shows the marketing manager “deciding” a company-wide policy, you have an authority problem, not a logging problem. The decision-maker field should prompt a real question each time: did this person have the right to decide this? If not, escalate before logging.

4. Burying the log where nobody looks. A decision log in one person’s private notebook helps one person. Keep it in a shared location the whole management team can access and search. The log’s value is collective memory, it only works if the collective can reach it.

Who Needs to Sign Off

The person who made the decision confirms the log entry, they check that the decision and reasoning are recorded accurately. The log owner (often an operations manager, project manager, or executive assistant) maintains the document and chases missing entries. For decisions above a spending threshold or with strategic impact, the senior approver should confirm the entry too. Nobody approves the log as a whole; each entry is verified by its decision maker.

How Often to Review and Update

Add decisions as they’re made, a log updated in batches every quarter will miss half of them. Review entries with upcoming review dates monthly: is the decision still valid, or does it need revisiting? Once a year, audit the log itself: are entries complete, is the reasoning recorded, are review dates being honoured? A yearly audit turns the log from a filing habit into a genuine governance tool.


Download the free Decision Log Template.