Risk Log: Score, Assign, and Review Project Threats

A risk score is a sorting tool, not a prediction

A score does not tell you that a project will fail, nor does it make uncertainty disappear. It gives a team a consistent way to compare threats and decide which ones deserve attention before the next checkpoint. That distinction matters: a risk log is not a catalog of every imaginable inconvenience. It is a short working list of conditions that could change delivery, scope, cost, quality, or a promised outcome.

Use two ratings, each on a scale from 1 to 3. Multiply them to create a score from 1 to 9. The scale is intentionally compact. A 3-by-3 grid is quick enough to use in a short team review, while still separating a likely nuisance from a less likely event with serious consequences.

Multiply likelihood by impact. A score of 1–2 is generally a watch item, 3–4 merits a named response and a review date, and 6–9 needs an active mitigation or a clear contingency. These bands are operating conventions, not universal laws. A team may decide that any risk affecting a legal obligation, safety requirement, or immovable launch date gets immediate attention regardless of its arithmetic score.

Do not treat the number as more precise than the evidence behind it. A score of 6 is not “twice as dangerous” as a score of 3. The useful question is what the score helps the team do next: investigate, reduce exposure, prepare an alternate route, or accept the risk knowingly.

The working risk-log template

Keep the log close to the plan, in a shared document or project workspace the team already checks. If maintaining it becomes a separate administrative project, the format is too heavy. Start with one row per specific threat and include enough information for someone other than the original writer to understand what to watch.

For a compact log, the owner field can be a role—“operations lead,” for example—if the person is clear to the team. Avoid assigning a risk to “everyone.” Shared awareness is useful; shared accountability often means nobody knows who should make the next call. If ownership changes, update the row rather than relying on an informal handoff.

Include the cause as well as the possible event. “Launch delayed” describes an outcome, not a useful risk statement. “The launch may slip because the supplier has not confirmed the delivery slot” gives the owner something to investigate. A well-formed risk can often be read as: Because of [cause], [uncertain event] may happen, affecting [objective or milestone].

Keep the response concrete. “Monitor closely” is not a mitigation unless it says who monitors what, how often, and what action follows a signal. “Operations lead checks the supplier portal every Tuesday and requests escalation if the date is unconfirmed by Day 10” is observable. It creates a small, verifiable action instead of a reassuring phrase.

Worked example: a supplier delay with a score of 9

Imagine a 90-day product rollout that depends on printed materials arriving before a pilot scheduled for Day 35. The supplier has not confirmed a delivery date. The team rates likelihood 3 because the order is still unconfirmed and the delivery window is narrowing. It rates impact 3 because missing the shipment would prevent the pilot from running as designed. The score is 3 × 3 = 9.

The score does not demand panic. It demands a decision while there is still room to act. The owner might be the operations lead, who contacts the supplier by Day 5, requests written confirmation, and checks whether partial delivery is possible. By Day 10, if there is no firm commitment, the owner obtains a quote and lead time from a backup supplier. The project lead then decides whether to switch, adjust the pilot materials, or move the milestone.

That sequence separates mitigation from contingency. Mitigation reduces the chance or effect of the threat: confirm production status, clarify shipping dates, or split an order. A contingency is the prepared response if the threat occurs: use the backup supplier, run a smaller pilot, or change the pilot date. Both belong in the log when the consequences justify the effort.

Also state the decision boundary. “Switch suppliers if the original supplier cannot provide written confirmation by Day 10” is more useful than “consider alternatives.” A boundary prevents the team from repeating the same discussion at every meeting while the delivery window quietly closes.

Assign ownership without turning it into blame

A risk owner is responsible for keeping a specific threat visible and moving its response forward. The owner does not have to control every cause. A project coordinator cannot make a vendor ship faster, for example, but can request confirmation, track the trigger, surface a missed commitment, and bring a decision to the right person.

Make the assignment explicit in the kickoff meeting. For each high-scoring risk, ask the owner to confirm four things: what evidence they will watch, what action they can take directly, when they will escalate, and who has authority to approve the contingency. This small conversation exposes gaps that a name in a spreadsheet can hide.

• Evidence: What observable signal would make the risk more or less likely?
• Action: What can the owner do before that signal becomes a blocker?
• Escalation: What threshold requires a decision from the project lead or sponsor?
• Authority: Who can approve extra spend, a scope change, or a date change?

Where two teams share a dependency, nominate one coordinating owner and list the contributing roles in the response. For instance, a data migration risk could have an engineering owner, with a product manager responsible for approving the fallback scope. This preserves a clear point of contact without pretending that one person can perform every part of the response.

Ownership is not a verdict on who caused the risk. A useful log makes it safer to report a weak signal early. If people expect blame for raising a concern, they tend to wait for certainty—and by then a preventable threat may already be affecting the schedule.

Write triggers you can actually observe

A trigger is an event or threshold that tells the team the risk needs attention. “If things get worse” is not a trigger. “If the approval is not received by the end of Week 2” is. A good trigger is specific enough that two people reviewing the project would agree whether it occurred.

Useful triggers include a dependency not confirmed by a stated date, a test failure above a defined threshold, a key role remaining unfilled after a hiring checkpoint, or a forecast showing that the team has less capacity than the plan requires. Choose a signal early enough to preserve options. If the trigger only appears on the day a milestone is due, it may describe a blocker rather than provide warning.

Triggers should connect to the project’s actual delivery mechanics. In a learning sprint, a trigger might be missing two scheduled practice sessions in a week; the response could be to reduce the resource list or reserve a protected study block. In a client project, it might be a review decision not received within five business days; the response could be escalation or a revised approval path. The point is not to track every fluctuation, but to notice changes that alter the plan.

A 90-day review rhythm that fits the cycle

Review the log at kickoff, then on days 30, 60, and 90. These dates create a simple backbone for the cycle, but they do not replace regular project check-ins. A high-scoring risk with a trigger due next week should be reviewed next week—not left untouched until Day 30. Put the next review date in each row, based on how quickly the situation could change.

Run a focused review rather than reading every row aloud. Start with score 9 and score 6 items, then any risk whose trigger is due before the next checkpoint. Ask the owner for a short status: what changed, what evidence supports the current rating, what action comes next, and whether a decision is needed. Record the decision and its date in the same place as the risk.

At Day 30, compare the original assumptions with what has actually happened. If an approval arrived early or a supplier confirmed the shipment, lower the likelihood only when the evidence supports the change. At Day 60, put particular attention on the final month: there may be less time to replace a resource, alter scope, or rebook a launch. At Day 90, do not simply archive open items. Decide whether each one has expired, been resolved, or must be carried into the next cycle.

Change scores when the evidence changes

Scores are snapshots, not permanent labels. If a vendor confirms a delivery date and provides tracking information, likelihood may fall. If the milestone moves closer and there is no backup option, impact may rise. Keep the original reasoning brief enough that someone can see why the rating changed; “score changed” without a note makes the log difficult to trust.

Do not lower a score just because the owner completed an action. The question is whether exposure changed. Sending an email to a supplier is an action; receiving a confirmed delivery date is evidence. Likewise, a risk can become more serious even if nobody has reported a new incident—for example, when a decision deadline passes and fewer alternatives remain.

When the team disagrees, record the rationale and choose a temporary rating that prompts a sensible response. If one person sees a 2 × 2 and another sees a 3 × 3, ask what evidence would resolve the gap. The discussion may reveal different assumptions about the milestone, the available fallback, or the amount of time left. That is valuable information the score alone cannot provide.

Keep the log small enough to use

A long list can create the illusion of control while burying the risks that matter. Add a risk when a defined event, dependency, or assumption could affect a project objective. Do not add vague worries simply to show that the team has considered every possibility. If several entries describe the same underlying threat, combine them and list the related consequences or milestones.

At each review, give every open row one of four outcomes: keep it open with a next action; change the score or response; close it because the trigger passed or exposure ended; or carry it forward because the risk remains relevant. Closing a row should include a short reason. “Closed—supplier delivered and materials passed inspection” is more useful than a blank status.

Keep risk and issue distinct. A risk is uncertain: the supplier may miss the date. An issue has happened: the supplier has missed the date. Once a threat becomes an issue, update its status and move the response into the project’s issue or action tracking process, while preserving the history if it helps explain a delay or decision. This prevents a team from calling an active blocker “a risk” for weeks without addressing it as a present problem.

Common scoring mistakes—and a better alternative

• Scoring by instinct alone: Name the evidence behind each rating, such as an unconfirmed dependency, a missed test, or a shrinking decision window.
• Giving every risk a high score: Compare impacts against the same project objective and reserve the top ratings for threats that could materially change delivery.
• Using a score as a substitute for judgment: Apply an override for safety, regulatory, contractual, or reputational consequences that need attention even when the numeric score is modest.
• Assigning an owner without authority: Name the person who can act, then name the decision-maker who can approve a contingency when needed.
• Reviewing only on a fixed monthly date: Keep the Day 30, 60, and 90 checkpoints, but set earlier row-level dates for fast-moving threats.
• Closing risks because the project is nearly over: Close only when the exposure has ended, the trigger has passed, or the item has been deliberately transferred to a new cycle.

A 15-minute risk-log review

For a small team, a short agenda is often enough to keep the register alive. Bring the current log and the next milestone calendar. Spend the first two minutes checking what changed since the last review. Use the next eight minutes on the highest scores and triggers due before the next meeting. Reserve three minutes for decisions or escalations, then use the final two minutes to confirm owners and dates.

1. What changed? Add newly observed threats and update facts, not speculation.
2. What could affect the next milestone? Prioritize by exposure and timing, not by which item is easiest to discuss.
3. What will the owner do next? State one observable action and a due date.
4. What decision is blocked? Name the decision-maker and the latest useful decision date.
5. What can be closed? Record why the threat is no longer relevant, or carry it forward explicitly.

The result should be a small set of decisions, not a polished spreadsheet. If a review ends with no owner, action, trigger, or date changing, check whether the meeting is looking at evidence or merely repeating the same status.